🚀 go-pugleaf

In article <9106010224.AA28532@ucbvax.Berkeley.EDU> jbs@WATSON.IBM.COM writes:
 >
 >          Henry Spencer says:
 >My understanding is that the funnier-looking features, in particular the
 >infinities, NaNs, and signed zeros, mostly cost essentially nothing.
 >
 >          I believe this statement is incorrect.  Infs and nans compli-
 >cate the design of the floating point unit.  Even if there is ultimately
 >no performance impact, this added design effort represents a very real
 >cost.  Perhaps some hardware designers could comment.

     With my previous employer I helped design several floating point
units and in my experience the most difficult part of the IEEE
specification to handle were the denormalized numbers.  The
infinities, NANs, signed zeros, and rounding modes do not make the
hardware substantially more complicated or significantly decrease
performance.  As has been pointed out in other related postings these
features can be valuable for many numerical algorithms.  The value vs.
cost for denomalized numbers though is not favorable IMHO.  I feel a
representation for an infinitely small non-zero value would be useful
and much easier to implement in hardware.  But if you have to be able
to say that your device is 100% IEEE floating point compatible you get
stuck implementing the entire standard no matter what the hardware
tradeoffs.

     A related method we also employed on another device that did not
have to be 100% compliant may be of interest.  This device performed
both single precision integer and floating point operations.
Therefore we had a full 32 bit adder and multiplier available.  For
this device we made the on board register file 40 bits wide, 8 bits
for exponent and 32 bits for sign and mantissa.  Without going into
all the details, the integer operands used the 32 bit field and were
processed in a normal manner (exponent field was passed unchanged).
Floating point was performed using the full 32 bit mantissa with
rounding only on output from the chip.  This carried an extra 8 bits
of precision from intermediate operations which remained within the
chip.  The chip also could extract the exponent field into an integer
so we could emulate multiple precision in software if desired.  Not
exactly IEEE standard but probably would work well for many real
applications where better precision is more important than rigorous
numerical error bounding.   



--

Dale C. Earl                                                dce@mitre.org
These are my opinions, only my opinions, and nothing but my opinions! DCE