On Mon, Apr 03, 2000 at 05:45:12PM -0700, David Querbach wrote:

 > Upon further examination, I found another floating-point emulator in
 > /usr/src/lib/libc/arch/arm32/fplib and in usr/src/lib/libc/arch/mips/fplib.
 > This emulator _does_ seem to support signals and rounding modes.  The arm32
 > port appears to always use the emulator, whereas the mips port appears to
 > never use it.  Strangely, the sh3 port seems to refer to the emulator
 > without actually including it.

Right, so the arm32 port always uses it because the ARM basically never
has floating point harware.  In the ARM case, there *used* to be an in-kernel
floating point emulator, but it was a binary-only thing, and was eventually
ditched in favor of the userland solution.

In the MIPS case, the emulator was added to libc for the e.g. NEC VR4100,
used on many WinCE handhelds.  These have no floating point hardware.

However, the dilemma here was that it added an new MIPS ABI to NetBSD,
which was suboptimal; there are already multiple mipsel ports in NetBSD,
and requiring one of them to use mipsel-softfloat meant that we couldn't
leverage package builds, snapshot builds, etc.

It also turned out that the softfloat-in-libc turned out to be a fair bit
faster than kernel fp emulation for *statically linked* binaries, but MUCH
much slower for *dynamically linked* binaries.  Obviously, the performance
of kernel fp emulation is the same for statically linked or dynamically
linked binaries.

For this reason, the MIPS port has gone to totally kernel fp emulation.

This is probably what we should do for the PowerPC, as well.

 > 3.  Use #ifdef SOFT_FLOAT to conditionalize several files in
 >     src/lib/libc/arch/powerpc/gen which now assume the existence of hardware
 >     floating point.

Which are these?

(BTW, in any case, it should be -D__SOFT_FLOAT, to keep it out of the user's
namespace :-)

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>