> I have no intention because in-kernel FPU emulation _is_ required to
> run R2000/R3000.  Even with FPA-equipped R2000/R3000, FP insn emulation
> have to be done because, some of FP insns _might_ emit NOTIMPLEMENTED
> exception and/or post interrupt signal line.

Here goes more rumbing version.  Following was provided by Kazumasa
Utashiro, one of my ex-colleague, who ported 4BSD-at-the-time to SONY
NWS3400 while residing in Cupartino around '92 interfacing with UCB
CSRG.  (4BSD-at-the-time and CMU Mach for OMRON LUNA would be another
rumbing story). 

When MIPS started designing FPA, transistor was scarse resource.  Some
_implementation_ of R2000 (R3000?) processors lacked some portion of FP
insns, so they should be emulated by operating system software.  The
_degrees_ of hardware implemented FP insn completeness _varied_ from
one implementation to another.  So, all of FPA insns should be emulated
by kernel software anyway.  MIPS started FP insn definition w/o
hardware implementation, then gradually added FP hardware.  That's the
reason why fp.S was made, and the exact reason why IDT, TOSHIBA/PHILIPS
or NEC could safely eliminate FPA hardware from their own variations
later; if FP insns is necessary to run, FPA emulation by kernel is
(was) pre-requisite, and there was no lossage from kernel software's
point of view.

So, there was no necessity to introduce NOFPU/SOFTFLOAT kernel option
(the latter is apparently misnomer because it would say "support FP insn",
while contradicting to -msoft-float flag for "never-use FP insns"), OK?

Tohru Nishimura