Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!WATSON.IBM.COM!jbs
From: jbs@WATSON.IBM.COM
Newsgroups: comp.arch
Subject: un-normalized floating point etc
Message-ID: <9105210333.AA09960@ucbvax.Berkeley.EDU>
Date: 21 May 91 02:16:39 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 52


          Herman Rubin writes:
The last question first:  How about multiple precision floating (or fixed)
arithmetic?  Considering that there are quite a few papers on this, it is
certainly a topic of interest.  I do not believe it should be necessary here
to go into the full range of situations I can list NOW where this would be
useful.
Now what is the benefit of allowing only normalized floating point?  It
eliminates the need for a normalization option in floating instructions,
and it provides ONE more bit of accuracy.  Is that ONE bit exactly what
is needed?  This is very unlikely.
Now what is the cost of not having forced normalization, besides the one
bit?  There would have to be a method for indicating which result of the
operation is wanted (upper, lower, normalized).  There would be little
additional hardware other than the decoding, by the floating unit, of
this information.

          Well the main cost of not having forced normalization is
that your floating point format becomes incompatible with everybody
else's.  When a standard becomes as entrenched as the ieee floating
point standard has become in recent years its technical merits or
lack thereof become almost irrelevant.  This is the main reason the
IBM Risc System 6000 uses IEEE.  (Does anyone know of any recent
designs which don't use IEEE?)
          Also your claim that there is little hardware cost is de-
batable.  If your multiplier must be able produce the normalized
product of two unnormalized numbers, the normalization stage has to
be able to handle shifts of 100 bits (instead of 0 or 1 only).  As
well as adding hardware this may slow you down.
          Finally regarding multiple precision floating point
arithmetic. If you mean twice working precision I fail to see the
benefit of having unnormalized floating point operations.  The
Risc System 6000 is able to provide software quad-precision arith-
metic with the current instructions.  If you mean more precision
than this I believe this is very little used.
          Herman Rubin also writes:
So why not have increased integer accuracy?  It is no harder to do this, and
the same units can be used.

          I believe there is a good argument for 64 bit integers.
However as someone already pointed out 64x64 bit multiplies can
not be done with a 53x53 bit floating point multiplier.
          Herman Rubin also writes:
The chicken and the egg again.  Anyone who is willing to say that something
is not useful is either ignorant, arrogant, or stupid.  Nobody can, or should,
attempt to ever do this.  Even the best people can make big mistakes.

          Well when a architect leaves something out he is not say-
ing it is useless, he is saying its benefits do not match its
costs.  Btw I suspect to be a good designer you need a bit of arro-
gance.
                        James B. Shearer