quoted
While I was puzzling over that (stepping through a SIGFPE handler in
gdb), I noticed something disturbing: some newly created processes
(grep and more and other random programs) started dying with unhandled
"Floating point exception" messages. I'm at a loss to explain this,
but I saw it happen often enough to be convinced that I'm not imagining
the behavior. I do wonder whether "lazily" enabling the FPU (and
enabling FPU exceptions) when FPSCR[FEX] may be set is really a good
quoted
idea.
...
quoted
I guess that I'm reporting a bug (or a few bugs) here; I certainly
understand the motivation behind doing lazy FPU switching, but question
whether it's done with adequate care when FP exceptions are enabled.
It is a bad idea, because gcc now uses FP registers to copy structs.
Every program can be an FP program now, so why add complexity and
keep taking traps?
One thing to keep in mind, GCC is perfectly capable of compiling without
using floating point. I routinely use code that has no floating point
compiled in (including glibc). If you build a system with -msoft-float
(libraries through the apps) then the FPU never gets enabled and your
context switching is faster. (Is this measurable? I'm not sure.
But..) The system "seems" to preform better.
Lazy FPU initialization IMHO is a good thing for single purpose
(embedded?) systems that are on a high end CPU, but do not need floating
point. One example could be a signal processing system that uses
altivec and integer math heavily, but no floating point.
--Mark Hatle
MontaVista Software, Inc.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Mark Hatle writes:
[Albert Cahalan]
quoted
[somebody]
quoted
quoted
[about lazy FP save/restore]
It is a bad idea, because gcc now uses FP registers to copy structs.
Every program can be an FP program now, so why add complexity and
keep taking traps?
One thing to keep in mind, GCC is perfectly capable of compiling without
using floating point. I routinely use code that has no floating point
compiled in (including glibc). If you build a system with -msoft-float
(libraries through the apps) then the FPU never gets enabled and your
context switching is faster. (Is this measurable? I'm not sure.
But..) The system "seems" to preform better.
Maybe your gcc can't take advantage of FP registers for non-FP uses.
Your non-FP code might seem a wee bit better, but your FP code
ends up taking faults. Then with all the extra code, we end up
with extra problems -- for example the original poster's trouble.
Lazy FPU initialization IMHO is a good thing for single purpose
(embedded?) systems that are on a high end CPU, but do not need
floating point. One example could be a signal processing system
that uses altivec and integer math heavily, but no floating point.
That is almost exactly the sort of system I work with.
AltiVec is used for signal processing, though with "float" data.
FP registers are still useful, for struct copies and for the
occasional standard C library function.
I suppose, if one does want lazy FP save/restore, that it ought
to be done with a per-process flag to prevent frequent faults.
When switching to an FP process, restore the registers. From time
to time take away the FP registers to deal with processes that
only use them once in a great while or only at startup. Maybe
take away FP after 1, 2, 4, 8, 16... ticks of use.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
quoted
Lazy FPU initialization IMHO is a good thing for single purpose
(embedded?) systems that are on a high end CPU, but do not need floating
point. One example could be a signal processing system that uses
altivec and integer math heavily, but no floating point.
Your non-FP code might seem a wee bit better, but your FP code
ends up taking faults. Then with all the extra code, we end up
with extra problems -- for example the original poster's trouble.
Maybe I missed something here, but my understanding is that if you in
SMP lazy initialization never happens. And if you are single CPU you
take _ONE_ fault per process.
One FP fault per process seems very minor to me, (unless of course you
are spawning a hell of a lot of process, but most likely the process
spawn time would outweigh the single fault.)
I suppose, if one does want lazy FP save/restore, that it ought
to be done with a per-process flag to prevent frequent faults.
When switching to an FP process, restore the registers. From time
to time take away the FP registers to deal with processes that
only use them once in a great while or only at startup. Maybe
take away FP after 1, 2, 4, 8, 16... ticks of use.
That might be of some value, but I'd be concerned that instead of 1
fault per process we could run in to a lot of faults, or into a
situation where each process would need some type of a counter to detect
faults. (Probably messy...)
--Mark Hatle
MontaVista Software, Inc.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/