[E-Lang] Operators #6: Multiplicative operators

[Karp, Alan]

> -----Original Message-----
> From: shap@cs.jhu.edu [mailto:shap@cs.jhu.edu]
> Sent: Tuesday, May 01, 2001 5:01 AM
> To: e-lang@eros-os.org
> Subject: Re: [E-Lang] Operators #6: Multiplicative operators
> 
> 
> Years ago, I discussed this with Robert Montoye at one point, who
> designed the floating point unit on the RS6000. That unit used hex
> arithmetic, and this rounding rule created a real mess because the
> machine had additional internal precision that it actually used in the
> multiply-add unit.  The round to even rule created yet more 
> cases where
> the MADD unit would produce a different answer than a 
> multiply followed
> by an add (which was a dumb thing for them to do, and fixed in later
> machines).

My recollection is quite different.  I was working for IBM at the time the
RS6000 came out; it's arithmetic was IEEE standard.  I remember because it
was a BIG deal in IBM to have a machine with non-hex floating point.  For
example, executive approval was needed to pipeline the division on the
360/91 because it sometimes produced a 1-bit difference from the
non-pipelined result.  

I think the confusion is between the prototype and the product.  Peter
Markstein, one of the architects of the RS6000 says, "For a short while,
while the RS/6000 (code name, America) was just a Research project, the
arithmetic was going to be S/360 style hex. As soon as we got product
ambitions, we switched to IEEE 754."  

As a historical note, IBM came out with a board for the early PC that
emulated a S/360 architecture.  (I've forgotten the name, VM/PC I think.)  A
specially modified Motorola 68000 chip was used to produce IBM hex floating
point.

As far as MADD vs. multiply followed by add goes, it is true that you get
different answers, but MADD is always more accurate, having one rounding
instead of two.  The RS6000 still supports MADD.  The real issue is
different compiler optimizations generating different uses of MADD.  For
example, A*B+C*D can be compiled as

		x=mul(A,B); y=mul(C,D); add(x,y)
			or
		x=mul(A,B); madd(C,D,x)
			or
		x=mul(C,D); madd(A,B,x)

with potentially different results each time.  Most people agree that the
improved performance and accuracy outweighs the usually small changes in the
result.  I've always felt that if my bridge stands or falls based on the
roundoff characteristics of my program, I've got bigger problems than my
floating point arithmetic.

> 
> In any case, Hal's memory is consistent with my memory of that
> discussion -- given a choice between two rounding modes, the one that
> requires less precision is better. Remember that floating 
> point space is
> not real numbers -- it's a weird sort of tumbler space, so precision
> matters.
> 

I don't understand the comment about "requires less precision is better".
Truncation (round to zero) requires less precision (no sticky bit needed),
but is worse than round to nearest.

Of course, none of this has anything to do with the choice of round to
nearest even or nearest odd.  I'm still trying to track that one down.

_________________________
Alan Karp
Principal Scientist
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-3
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/