In article <19991016215812.A5832@pluto.geo.Uni-Koeln.DE>,
Dr. Lex Wennmacher <wennmach@geo.Uni-Koeln.DE> wrote:
>1) the kernel always saves and restores the FPU for the process when calling a
>   signal handler;
>2) the kernel does lazy saving of the FPU;
>3) libc provides routines to save and restore the FPU. It is the responsibility
>   of the programmer to call these if floating point arithmetic is done in a
>   signal handler.
>[4) I'm not shure about the following: in function calls, the compiler could
>    implement saving of the FPU by the callee (as an option)?]
>
>Option 1) may have performace impacts (on slow architectures). Option 2)
>is not possible on all architectures, I was told, because on some archs
>the FPU gets reset on disabling it. Option 2) could be made the default
>on archs that support lazy saving of the FPU, while on the other archs
>option 1 (probably as kernel or sysctl option) gets implemented.
>
>A simple userland solution is option 3). This option could also be used as
>interim solution until a kernel solution becomes available. 
>As an i386 example, see signal_save_fpu.c and fpu.{c,h} in the attached shar
>archive. 

We should go with option 2 for archs that can do it and option 1
for archs that can. We need the floating point state anyway for
the mcontext portion of struct ucontext (when our sigaction gets
the context stuff added). It is not acceptable to require userland
programs to call routines to save and restore fp state.

christos