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!linus!decvax!cca!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: Tue, 20-Aug-85 00:24:49 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