Browse Prior Art Database

Anecdotes: System 360 Floating-Point Problems Disclosure Number: IPCOM000129882D
Original Publication Date: 1995-Jun-30
Included in the Prior Art Database: 2005-Oct-07
Document File: 3 page(s) / 19K

Publishing Venue

Software Patent Institute

Related People

Robert E Rosin: AUTHOR [+2]


Enhanced Service Providers Zinc. Shrewsbury, N.J.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 34% of the total text.

Page 1 of 3


Copyright ©; 1995 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Used with permission.

Anecdotes: System 360 Floating-Point Problems

Robert E Rosin

Enhanced Service Providers Zinc. Shrewsbury, N.J.

The problem with the tables used to implement floating-point division in early Pentium CPU chips, which came to light at the end of 1994, has a remarkably similar precedent in the history of IBM's System/360 almost 30 years earlier.

As initially specified and implemented, the floating-point algorithms in System/360 rounded to the nearest 4bit byte, rather than to the nearest bit, producing results that were unacceptably imprecise. This problem was first spotted by Len Harding, then at the University of Michigan, and Bill Kahan, then at the University of California at Berkeley.

IBM initially denied that there was a problem and refused to make any changes. After some clamoring from SHARE, in 1965 or 1966 IBM finally retrofitted all the 360s that had been delivered, which amounted to a few thousand systems. There were then five models of System/360; in the three lower end models -- 30, 40, and 50 -- floating-point arithmetic was microprogrammed in read-only memory, so the fix required a relatively simple replacement of part of that memory. Repairing the higher end models -- 65 and 75 -- required replacing installed circuits. The use of microprogrammed implementation in the lower end models clearly saved IBM millions of dollars.

These two events, though separated by many years, share several characteristics:

1. They involved floating-point arithmetic. 2. The problems were discovered by (then) relatively unknown academics. 3. The products were produced by major corporations. 4. The companies first denied the significance of the problems. 5. They finally backed down and agreed to retrofit all installed systems.

Trite but true -- "Those who do not study history are doomed to repeat it."

Len Harding's view.

Bob's memory is pretty good, and I agree that the Intel situation today and the IBM situation in the late sixties have much in common. But I would term Intel's problem a bug, whereas IBM's problem would be better characterized as a shortsighted architectural decision. But there are also some glaring differences

First, there was no IEEE floating-point standard to follow in the sixties, and IBM made no claim that their architecture followed any particular standard. I have not seen any specific information from Intel that the Pentium implemented the IEEE standard, but I would assume such literature exists IBM was breaking new ground with hexadecimal floating point. In those days preshifting and postshifting to normalize fractions took one cycle per bit, and Sweeney's study showed that hex normalization would be a lot more efficient. Since pre- and postshift of arbitrary lengths are done in less than a cycle today (the whole fp addition only take...