dgh@validgh.com (David G. Hough on validgh) (05/25/91)
There's been a recent discussion in comp.arch about IEEE 754 arithmetic. The discussion has mostly taken for granted that the IEEE arithmetic has been widely adopted. The active topic was whether widespread adoption was because or in spite of technical features of the standard. The underlying assumption is false. Aside from Sun C and Fortran products, and Apple programming systems providing access to SANE, IEEE 754 arithmetic environments are extremely rare. What is most widespread is adoption of the least important part of IEEE 754, namely the single- and double-precision storage formats. (A followon, IEEE 854, is independent of radix and word length). What's mostly missing is language bindings to the features of IEEE arithmetic that are missing from conventional programming languages. There's a good reason for that; if the 754 committee had attempted to agree on language bindings it would have taken a very long time to converge and would probably have hit the wrong targets... such as Pascal, which appeared to be much more important than C twelve years ago. In any event a group called NCEG is now working on defining language bindings to ANSI-C. The widespread adoption of the storage formats, and also nowadays the default rounding mode, is somewhat a fortuitous coincidence of luck and timing. A number of microprocessor manufacturers simultaneously realized that there was a window of opportunity for getting computer arithmetic relatively correct and uniform, and were fortunate to receive a proposal that had more thought behind it than counting installed base. The most important aspect of IEEE arithmetic that is apparent in conventional language implementations is just this: The rounded computed result of a standardized operation depends only on the correct result and the rounding mode, and not on the operands nor on the operation. This may seem like an obvious requirement, but the only other commercially significant floating-point architecture that can make a comparable claim is DEC VAX. Indeed Mary Payne of DEC lobbied at great personal cost for adoption of DEC VAX format by the IEEE 754, modified by replacing D format with G format to obtain an 11-bit exponent field in double precision. And she might have prevailed but for a shortcoming of VAX exception handling: inadequate provision for nonstop exception handling. The only kind of exception handling that can be readily and universally specified is nonstop. The notions of continuable traps, error messages to the console, or core dumps don't make a lot of sense in embedded systems nor in many very high performance batch systems. The desire to obtain the same default performance in all environments leads to the following IEEE 754 features: nonstop default execution default results including subnormal numbers infinities signed zeros NaN's accrued exception-occurred status flags and these could not reasonably be accommodated in the VAX architecture. Furthermore Intel was known to be implementing the 8087 without undue difficulties, which was reassuring with respect to the relatively unfamiliar features proposed for IEEE 754. So the majority of committee members were eventually convinced that what was first called the KCS and later the CKPPS proposal was the right one to adopt. I can speculate that in some cases there may have been a desire to avoid giving DEC, or any other mainframe or mini manufacturer, a built-in advantage by adopting its architecture, but with the benefit of hindsight some of those people probably should have been worrying about Intel instead. Anyway all this happened at about the same time that IBM adopted the 8086 for its PC, Apple adopted the 68000 for the Macintosh, and a number of people were thinking about building something like an Alto out of standard parts like a 68000, BSD Unix, and a really big screen. Once the bandwagon started to roll, customers started putting IEEE standard arithmetic on their checklists, whether they needed it or not, just as they did with many other checklist items. Now it is rumored that the last mainframe holdouts, Cray and IBM, will eventually offer additional instructions supporting IEEE formats to some extent. The most problematic aspect of IEEE arithmetic for hardware implementors is handling subnormal operands and results in pipelined implementations. These cases are relatively rare but not so rare in some programs that software emulation is transparent. My own opinion is that subnormal operands and results should be considered in the same light as cache misses, part of the cost of doing business, and should be handled in a somewhat similar manner as bubbles in the pipe. A benefit of subnormal operands and results is that underflow is not an issue for addition and subtraction, which figures in program that exploit divided differences with code like if (x .ne. y) z = w / (x-y) Subnormal results also permit underflow to be no more consequential than ordinary roundoff in most other computations, too. But hardly anybody is aware of that because most IEEE arithmetic features are intended, whenever possible, to put the burden of thinking about them on the implementors rather than the end users. Getting correctly-rounded products, quotients, and square roots is harder than doing them like a Cray, but the hardware that does these things can be integrated reasonably well as on the TI 8847. Pipelining is still a problem, but one which perhaps will ultimately be handled supercomputer-style with large multiplier arrays and multiple divide/sqrt functional units. And it's always cheaper to do it right in hardware than to try to work around cheap hardware in software. For those who enjoy the latter challenge, the sons (in spirit) of Cray will continue to produce partial IEEE implementations like the Intel 860 which are as effective in certain limited applications as they are difficult to exploit more generally. -- David Hough dgh@validgh.com uunet!validgh!dgh na.hough@na-net.ornl.gov