Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!emory!att!ima!esegue!johnl
From: johnl@esegue.segue.boston.ma.us (John R. Levine)
Newsgroups: comp.arch
Subject: Re: IBM S/360 FP (was Re: RS6000 Multiply/Accumulate instruction)
Message-ID: <1990Mar15.024343.5126@esegue.segue.boston.ma.us>
Date: 15 Mar 90 02:43:43 GMT
References: <8888@boring.cwi.nl> <8370@hubcap.clemson.edu>
Reply-To: johnl@esegue.segue.boston.ma.us (John R. Levine)
Distribution: comp
Organization: Segue Software, Cambridge MA
Lines: 45

In article <8370@hubcap.clemson.edu> mark@hubcap.clemson.edu (Mark Smotherman) writes:
>  [report of 1983 IBM justification of the 360's floating point]

There was an article in the IBM Systems Journal in 1964 explaining the design
of the FP system.  They did indeed get a big speed increase by normalizing in
hex rather than binary, but they didn't understand the precision hit they were
taking.  In particular, their analysis assumed that leading digits of FP
fractions are uniformly distributed, but actually they're geometrically
distributed.  This means that they thought that there would be an average of
one leading zero bit, but actually there are two.

Also, the hidden bit trick common in binary FP systems doesn't work in larger
bases.  (In fairness, the PDP-6 floating point which was designed at about the
same time didn't use a hidden bit either, but it did let you use fixed point
compare instructions to compare normalized floating point numbers, a
significant simplification in the CPU design.)  This lost another bit.

As another speed hack, they truncate rather than round FP results which loses
another bit.  In aggregate, these three decisions lost three bits, almost a
full digit, compared to a binary FP format like the PDP-11's.

>  In System/360, the loss of precision was quite acceptable for the long 
>format. ...

Uh huh.  When people moved their numerical programs from the 7094, which
had a binary 36 bit FP format to the 360, in most cases they had to
change all of their REAL variables to double precision at a severe cost in
memory, which was very expensive, and in performance since they didn't really
need double precision, just something better than the 360's cruddy single
precision.  The name of the program they used to do that, SIFT, has since
become a generic term for source-to-source translators.

Furthermore, the original floating point units didn't even have guard digits!
The numerical analysis crowd screamed so loudly that IBM quickly added guard
digits to the FP units and field upgraded all of the existing machines for
free.

I have never understood why the 360's floating point was botched so badly.  As
far back as the 1940s and perhaps even before IBM had excellent numerical
analysts on staff, and it seems strange to me that none of them seem to have
been involved in the 360 design.
-- 
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl
"Now, we are all jelly doughnuts."