🚀 go-pugleaf

         I said:
>          Also as has already been pointed out there is a software cost
>due to such features as 0*x no longer being 0.  In some cases this will
>have a performance impact in that compilers will generate inferior code.
         Jim Dehnert said:
As a compiler writer who has worked with IEEE systems, I don't know
why, at least in any area with an important impact on performance.
The reason for the IEEE definition (0*Inf=NaN) is that zero may
represent a result merely close to zero, and Inf really represents a
very large number -- I can pick representatives of these sets which
multiplied together give me a true result in the representable range
(not zero or Inf).  If I see a literal zero while compiling (the only
case I can think of when the compiler does anything that might care
about what 0*x equals), I feel quite free to assume that it is really
zero, in which case 0*x is really zero even for very large x.  So I
will do the same thing I would have for non-IEEE.  (This is the only
case I'm aware of where IEEE defines 0*x != x.)

         Some people write:      IF(0.D0*X.NE.0.D0)THEN
to detect infs or NaNs (see recent posts to comp.land.fortran).  This
works on many systems.  If you replace 0*x with 0 then it will not work
on your system and your system is broken.
         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.
         Jim Dehnert also said (referring to trapping floating overflow):
It is the case.  It's also perfectly achievable behavior for IEEE
systems if exceptions are trapped.  This has nothing to do with the
IEEE standard.  Instead, it's probably a result of default Unix
software behavior, which is not to trap in most implementations.

         Possibly I should be blaming Unix.  I tend to associate the
two.  Note in Goldberg's paper he suggests rewriting x/(1+x*x) in a
way which assumes trapping is not occurring.
         I said:
>          79 bits is clearly an absurd length for a floating point
>format (the same is true of the 43 bit single extended format).
         Jim Dehnert also said:
An interesting statement.  Are you of the "only powers of two are real
numbers" persuasion?

         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.
         Herman Rubin asked:
Why should it even be the case that the exponent and significand are in
the same word?

         Because if they aren't every load or store will require 2 mem-
ory references instead of 1 halving the speed in many cases.
                       James B. Shearer