🚀 go-pugleaf

In article <23659@winchester.mips.COM> mash@mips.COM (John Mashey) writes:
>In article <42942@bbn.COM> slackey@BBN.COM (Stan Lackey) writes:
>>This is true, and makes me believe that IEEE FP and RISC are
>>incompatible.
>
>This seems to be an over-generalization.
>Anyway, please explain
>more why IEEE FP and RISC are incompatible, ...


Sure.  As I understand it, the major basis of RISC is:

Simplify the hardware.  Include only those features that:
  Provably improve performance;
    Their presence speeds up certain operation(s)
    Their presence does not slow down other operation(s)
  Are straightforward to implement;
  Are usable by straightforward compiler design;
  Anything else emulate in software.

[I'm going to let it stand here.  Probing more deeply into any of the
above is a separate discussion.]

IEEE floating point goes contrary to each of those issues.

1. Gradual underflow is not straightforward to implement.  It requires
more cases to be handled in virtually every fp operation, for example
pre-alignment before multiplication.  Now you can leave time before
every multiplication for this prealignment (Cydrome), you take a
special control flow to handle the case (68881 etc), you just zero the
operands/results and ignore it (essentially what DEC, Cray, IBM, etc
do), or you trap to the OS (i860).

BTW [at least] DEC has trap-on-underflow.  Guess what happens real
quick?  Users shut it off.  [Was that necessary? Bad boy. -Ed.]

Gradual underflow does not improve performance.  It [inaccurately]
extends the low end of the range a little.  It adds significantly to
design and verification time.  The only case I ever heard of it
mattering is a drummed-up case Kahan wrote.

This does not affect the complier, other than requiring the runtime
libraries to be able to convert yet another format on output.

In the case of an i860 software supplier, if he wants stuff like
transcendentals to run fast, he must tune them so that they don't
cause underflow traps.  Rather that just use 0 which is what he wants
anyway.

2. Rounding modes.  No compiler on Earth uses them, other than to get
around instruction set deficiencies (rounding when converting from
FP to integer).  This particular problem is more efficiently solved by
adding a second version of the convert-to-integer instruction.

Their use has been intended for range arithmetic.  Now, when I asked,
lots of people knew what they were for, but no one [on comp.arch] had
ever heard of them having ever been used.  Interesting how much
hardware out there can do these operations that are so rarely used.
Kind of like the decimal string instruction set on the VAX, except
that the VAX decimal strings are occasionally used. [There you go
again! -Ed.]

Their implementation requires not much logic (maybe 50-100 gates), but
logic that affects critical path timing.  It requires yet more
verification (test vectors).

--
My belief is that if IEEE FP had been done a few years after it
actually was, after RISC became the trend, it would have come out much
different.  In fact, I think the suppliers should get an official
subset recognized by the IEEE that just uses 0 for underflowed
operands/results, and just implements round-to-nearest.  I would be
very surprised if it ever came up in a sales situation anyway; in fact
all I care about is how fast it runs SPICE.

I'm done.  [Finally! -Ed.]  -Stan