> Kernel questions:
> 1) If you have a 486DX with a math fpu, do you want or need the npx line
>    in the kernel config?

Yes.  However, you don't need MATH_EMULATE.

> 2) If you have this line, will fpu instructions invoke it, despite the
>    fact you have hardware to do it?

Yes.  Fpu instructions will use the coprocessor.  As I understand things,
npx is there to handle fpu exceptions, etc.

> Library questions:
> 
> 1) Currently, to get the math libraries (libm) to compile right, you
>    must edit the libm makefile.  What is the diff here?

You don't need to edit the makefile if you don't want to.  If you
uncomment the i386 specific ARCH_SRCS, assembly language versions
of the core trancendental and exponential functions will be used.
These use instructions not implemented by NetBSD's i387 emulator,
which is why they are not enabled by default.

>    If you do not use i387 in this makefile, does it do emulation with
>    integer code or something, or what?  It is somehow unoptimal to
>    simply use the same routines and simply emulate the unimplemented
>    fp instructions in the kernel?

If you don't enable the i387 specific code, libm uses the C language
implementation.  It is somewhat slower than the assembly code, but it
is actually more accurate in some circumstances (it handles some of
the corner cases like negative zero).

> 2) If the answer to #1 above was that we should do integer code emulation
>    in the library routines (or in some other way have the lib routines
>    differ based on the kernel configuration), what is the optimal way
>    to do this?  Should it ask the kernel about its configuration at
>    run-time?  sysctl?

In the ideal world, the kernel would support all the fpu instructions
and we wouldn't have to deal with this in the library.  We could have
the library functions detect whether a fpu was present and then vector
to the C or assembly implementation as appropriate.  But since the C
implementation is reasonable, I'd rather not.

	--jtc