> Hmpf.  This is the same problem 386bsd had at the start, and the
> solution (I think) was the elimination of dependency on an FPU by the
> kernel & c runtime library.

You're quite right, the kernel _should_ try to find out whether or not
an FPU is present, and then do the save/restore of the FP context
based on that.  the FP context save/restore is the only place in the
kernel that uses FP.  I take it that that's not currently done?

If there is no hardware or emulation to handle floating point
instructions, the system should still run, though things that use
hardware FP will die with a SIGFPE.  You'll note that some very basic
utilities, such as "fsck" will generate floating point instructions,
unless compiled with -msoft-float (or whatever that option is).

Binaries should be built with -msoft-float by default.  People who
were smart enough to buy math coprocessors should be able to use them
to full effect without any additional hassle.  It would be nice if
people who didn't buy them had an emulator, so that the system was
usable, but in my mind, people who bought the hardware shouln't
be penalized for others' lack of foresight.


cgd