On  04/15/2000 11:29:26,  Toru Nisimura writes:

>> 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.

That's mostly due to the FPA hardware not implementing IEEE denorms.
There's  a couple of other cases, but thats the big one.



>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?


The story I recall hearing from John Mashey in the late 80s is
slightly different...

At the time, the FPU and integer/TLB, weren't going to fit on one die
(compare to the first two sparc implementations, 68030/68851.)  Mips
did the normal thing for the time: one die with an integer CPU, and
another die with an FP co-processor.  Since gates were expensive and
denorms were "rare", and MIPS design was that hardware feathres had to
show a real performance improvement on their benchmarks suite, the FPU
designers chose not to implement full IEEE math in nardware.
Instead, denorms trapped and punted to software.

The exact details of just what might trap, what didn't, and how to
implement the glue, weren't documented in Kane's book.  CSRG (or Ralph
campbell directly?)  got some advice from someone at Mips/SGI about
how to do it.

So fp.s is designed to handle just the IEEE underflow and other
non-implementd portions of IEEE arithmetic. It's much more limited
than complete emulation of the floating-point instruction set, or
hardware that doesn't even implement the CP1 registers.

Some early vendors (including the Mips m/120!)  did make the FPU an
optional extra. Kernel software was supposed to cope with trapping
"all" instructions.  But NetBSD hasn't really bitten that bullet until
now.

Tohru's framework looks like  a very good start on that.