Path: utzoo!attcan!uunet!mstan!amull
From: amull@Morgan.COM (Andrew P. Mullhaupt)
Newsgroups: comp.arch
Subject: Re: Killer Micro II
Summary: Fixed point _seldom_ what I want.
Message-ID: <1628@s6.Morgan.COM>
Date: 5 Sep 90 12:15:54 GMT
References: <527@llnl.LLNL.GOV> <603@array.UUCP> <2482@l.cc.purdue.edu> <2510@l.cc.purdue.edu>
Organization: Morgan Stanley & Co. NY, NY
Lines: 65

In article <2510@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes:
> In article <1620@s6.Morgan.COM>, amull@Morgan.COM (Andrew P. Mullhaupt) writes:
> > In article <2494@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes:
> > > A reminder that for efficient really high precision arithmetic, INTEGER
> > > arithmetic is needed.  
> > 
> > No it's not. Check out some of the new machines - i486, RS/6000, i860,
> > where floating point is fast enough to make integer arithmetic a
> > poor substitute. Also check out a SPARC machine where integer operations
> > for multiplication and division are so slow that even bad floating
> > point competes.
> 
> You are confusing apples and oranges.  Poor integer facilities obviously
> will not beat simulating integer operations in floating point.  But thers
> is no good reason why nxn -> 2n multiplication, for example, should not
> be provided, where n is the largest word length available for floating
> point.
> 
> Notice that it is simulation of integer arithmetic in floating point which
> is used for high accuracy arithmetic.  It would be more efficient to provide
> the integer arithmetic directly, even if it must be done in the "floating-point"
> unit.  Integer arithmetic is not just for addressing and loop counting.

Yes, when you're up against it for high precision fixed point, you 
_can_ use floating point as a substitute. But for robustness and
accuracy,  I very often want floating point in the first place.

If you have several currencies, keeping accounts to the penny (or
Yen) means constant _relative_ precision, and this is almost a
specification for floating point. When you work to constant relative
precision, (and most things are like this outside of number
theory) that double-width multiplication is wasteful unless it's
really fast. (This is a really good example for the point of view 
that extra precision is a memory resource to be traded off for
time: the extra bits save you the trouble of shifting your result
and adjusting the exponent.) You are not going to opt for this if
you really want constant relative precision, i.e. you don't really
care about most of those extra bits, unless there is a savings.
Floating point is also much more robust when you go beyond just
simple arithmetic operations; you have an much greater range over
which your intermediate results can range before you have to lose
bits.

In some sense, floating point units were never really properly designed
until they were designed in a unified way, (IEEE-754/854). Once it 
became possible to think about the arithmetic without having to 
worry about which machine's floating point arithmetic, (and this is
one of the less heralded but quite important benefits of the
attack of the killer micros...) it was possible for the programmer
to begin to really understand and _rely_ on the available accuracy.
Until this point, you couldn't make an intelligent trade between
space (extra precision) and time. Now that you can, the real question
in architecture is "which one of these resources will be better used
by the programmer, and" (pace Herman) "his compiler". Let's face it;
the bulk of modern code is written via compilers and the bulk of modern
computing demands constant relative precision. Hardware floating point
is a good (effective and affordable solution). It has the great 
benefit that nearly interchangable instructions are found across a
wide range of machines. I don't really object if good integer arithmetic
gets put onto deficient (e.g. SPARC) machines. But if I can get floating
point to pipeline at one clock per result then I'll almost always take
the floating point. 

Later,
Andrew Mullhaupt