🚀 go-pugleaf

  I am not a numerical expert, but I was onthe mailing list of the IEEE floating
point committee when the standard was created.  At that time, I was a chemistry
grad student learning that Bevington's book did not prepare a physical scientist
for all the perverted things that computer hardware did in the name of floating
point.

In article <9106052113.AA14439@ucbvax.Berkeley.EDU>, jbs@WATSON.IBM.COM writes:
|> 
|>          Jim Dehnert also said
|> Round to +/- infinity give you the floor and ceiling functions, which
|> come up frequently, for example in many transcendental function
|> algorithms.
|> 
|>          This appears to apply just to convert to integer instructions.
|> Different modes could be offered for these instructions alone.  In any
|> case I don't believe they are useful for transcendental function algor-
|> ithms.  In fact the different rounding modes are a problem because the
|> functions must work for all modes.

  The main justification for having all the rounding modes was the +/- infinity
modes made creating an interval arith. package much easier.  As I recall,
without them an interval package could run 300x's slower than straight floating
point.  With them it was ca. 3x's slower.  Besides, these rounding modes were
cheap.

|> 
|>          Possibly I should be blaming Unix.  I tend to associate the
|> two.

  What does floating point hardware have to do with an operating system?  Unix
runs on mainframes and VAX's.  IEEE floating point is used on PC's (IBM clones,
Mac's, Amiga's) as well as work stations.



|>          I believe floating format sizes should be compatible with the
|> basic organization of the machine.  IE if your machine is based on
|> 8-bit bytes the length best be a multiple of 8.  I believe 32 or 64
|> bits are typical widths of data paths in current machines.  Therefore
|> moving 79 bit things around will clearly be wasteful.  Consider a
|> machine with 64 bit floating registers and a 64 bit data path between
|> the floating unit and cache.  I see no efficient way to include a 79
|> bit format.  An 128 bit format on the other hand is easily accomodated.

|>                        James B. Shearer

  The floating point chips from Intel and Motorola have 80 bit floating point
registers.  At the time, the standard developers decided that the main formats
should be a power of two in size so array addressing is fast, it is useful to
have a format with a wider mantissa to have guard bits, and a hardware ALU finds
it convenient to have the mantissa to be a power of two in size.  Putting the
last two points together gives a lower limit of 79 bits.  That is a wierd number
so Intel and Moto. rounded up to 80.  Actually, Moto. stores an extended to
memory in 96 bits so it is long word aligned.  If your compiler has good
register allocation, there will be little extended loads and stores.
  I expect you know this already, but I am trying to understand what you saying
above.  Supporting any format greater than the FP ALU is going to be slow.  What
IS so bad about extended?

  My experience in pre-IEEE FP days wasn't as nice as yours.  CDC's that I used
did not trap at all on overflow.  Instead the exponent wrapped around.  Not only
did systems not convert numbers like 12.0 accurately, the error was different
for program literals than for numbers read by I/O. ( For some reason, this
seemed un-natural to me them.  After all, it can be exactly expressed). 
Generally, I found programs than worked on VAX's had problems on IBM 360's and
blew up badly on Cybers unless I was very paranoid.  Nowdays, we have
occasionally found routines that work on IEE workstations (Apollo, Sun, HP) have
had problems on VAX,
which is my favorite of the pre IEEE formats.

Yours in number crunching,

Bruce Seiler

seiler@compass-da.com