Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.6.2.16 $; site ima.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!decvax!yale!ima!johnl
From: johnl@ima.UUCP
Newsgroups: net.arch
Subject: IBM 360 float architecture problems
Message-ID: <36900010@ima.UUCP>
Date: Mon, 15-Jul-85 13:19:00 EDT
Article-I.D.: ima.36900010
Posted: Mon Jul 15 13:19:00 1985
Date-Received: Thu, 18-Jul-85 06:23:28 EDT
Lines: 37
Nf-ID: #N:ima:36900010:000:2294
Nf-From: ima!johnl    Jul 15 13:19:00 1985


A while ago I said I'd send out a note on how the design of the floating
point unit on the System/360 was botched.  They ended up with a design
which is quite fast but produced poor answers, losing 3 bits of accuracy
in each operation.

Here's the sketch of what IBM did.  They seem to have thought that they could 
get faster floating point using hex rather than binary without losing 
precision, but they were wrong.  The analysis went sort of like this: We look 
at the high order digit of a hex floating point number.  Assuming that leading 
digits are uniformly distributed from 0 to F, on the average there will be one 
leading zero bit.  But since we use hex rather than binary exponents, we can 
make the exponent one bit smaller than if we had a binary exponent and the 
fraction one bit bigger, and you don't lose any precision, get better exponent 
range, and it's faster since you need fewer normalization steps to normalize 
hex rather than binary numbers.  

It turns out that leading digits are geometrically distributed so that on the 
average there are two leading zeros rather than one, so you lose one bit that 
way.  Also, when you use binary floating point you know that the high order 
bit of every normalized number is a 1 so you don't have to store it -- in hex 
this "hidden bit" trick doesn't work.  Third, the 360's floating point unit 
truncates results rather than rounding (again in the interest of speed) which 
is equivalent to keeping one less bit than if you rounded.  This means that
compared to a machine like the VAX, a 360 gets 3 bits less precision on each
floating point operation of the same word size.

The points about faster normalization were true, so the 360's floating point 
unit produces inaccurate results very quickly.  Originally, the floating 
point unit computed stuff only to the fraction size keeping no guard digits, 
which produced incredibly wrong results.  IBM retrofitted guard digits 
shortly after the first 360s were shipped and customers started to complain.  
Their eventual precision fix has been to add quadruple precision floating 
point, since it's too late to change floating point formats now.  

John Levine, Javelin Software, Cambridge MA 617-494-1400
{ decvax!cca | think | ihnp4 | cbosgd }!ima!johnl, Levine@YALE.ARPA