another comp.arch posting on IEEE 754 history

[David G. Hough on validgh]

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.