Notes from 754R meeting 12 Feb 2001

David Hough

The second meeting of the IEEE 754R revision group was held Monday 12 February 2001 at 11:00 am at Lana Networks, acting chair and host David James, standing in for snowbound Bob Davis. These notes are intended to give an informal flavor of the discussion. Attending were Joe Darcy, Dick Delp, David Gustavson, David Hough, David James, Rick James, David Scott, Dan Zuras.

A mailing list has been established for this work. Send a message "subscribe stds-754" to majordomo@ieee.org to join. Knowledgeable persons with a desire to contribute positively toward an upward-compatible revision are encouraged to subscribe and participate.

The next meeting was re-scheduled to Weds 14 Mar, place to be determined.

The bulk of the meeting was devoted to discussing various proposed revisions. The starting point was a draft mandated by the IEEE/CS Microprocessor Standards Committee which incorporated 854 and 1596. In its incorporated form, the draft appeared much too much like an external representation standard with a few afterthoughts about operations and rounding. Much of the external representation material can be removed, at least to an informative appendix; older IBM, Cray, and DEC proprietary formats are appropriately standardized by those manufacturers, and there is no value in adding an additional IEEE standardization of them; any differences would be accidental errors, and who needs that?

What to do about 854? It's currently a long appendix C. PASSED - eliminate 854 matter that strictly duplicates the binary standard, and retain the points of difference in the informative appendix. ACTION Hough: Write an introductory paragraph for paragraphs C 3.1-3.3, explaining that this specification should be followed for decimal floating-point arithmetic. [854's application to binary floating-point formats in other word lengths will be supplanted by other proposed changes in the standard.]

What to do about double-extended precision? The only significant current desktop implementation is IA32 (MC68K may still survive as a processor for embedded applications). There are some undefined aspects in 754 that would be well worth eliminating. One approach is to remove extended precisions from the standard. Another would be to standardize the current IA32 implementation exactly to discourage future minor discrepancies.

David Scott personally favors standardizing "short quad" rather than "extended double" - that is, a 128-bit format identical with the common 754-inspired quad specification, but with some significand bits unused (e.g. lower 49 bits ignored on read and zero'ed on write). Fortunately the exponent field would be 15 bits either way, but for some of the other proposed higher precision formats there would be a difference between n-extended and 2n-shortened:

Higher-precision formats: Zuras has proposed some higher-precision formats for word lengths of powers of two and 3*powers of two (e.g. 32, 48, 64, 96, 128, 192,...) and 1.5*n would have two extra exponent bits over n, and 2.0*n would have four extra exponent bits over n. An alternate proposal is that 1.5*n would have the same exponent as 2*n - four extra bits over n - and that would coincide for double-extended or short-quad. Another solution for double-extended would be to simply declare the IA32 80-bit format conforming. These inter-related issues were not resolved at this meeting. Kahan and others believe that standardizing variable precision is more worthwhile than adding quad or other higher precision formats, [although the only issue in the latter is the size of the exponent field].

Quiet/Signaling nans: One proposal is to require distinguishing Quiet/Signaling by the most significant bit of the fraction - 1 for quiet, 0 for signaling. PA-RISC has chosen the opposite convention, and although HP presumably is migrating to IA64, it seems that we can't render PA-RISC non-conforming with SHALL. PASSED - Quiet/Signaling SHOULD be distinguished as above.

Two quiet nans: 754 says one of the nans should be returned - implementations vary, e.g. SPARC specifies one of the op code registers - that's usually been implemented in software but in some cases by hardware. Should operations on two nans be commutative? That would imply that some kind of operation on the two nans be performed to determine which was chosen according to whatever rule were standardized. The hardware cost seems unlikely to be offset by any great benefit since specific nans are going to be machine-independent in any case. FAILED - motion to require commutativity on operations on two nans.

FMA exceptions : Should fused multiply add exceptions be based on two operations or one? The rounding/overflow/underflow is based on one operation, but what about 0 * inf + qnan ? Should this raise an invalid exception? Given the qnan, the 0 * inf invalidity seems uninteresting. PASSED - invalid exceptions SHALL be handled in a "fused" manner . ACTION Zuras: provide text for an FMA operation.

Binary-decimal conversion : PASSED - all binary-decimal conversions SHOULD be correctly-rounded . ACTION Hough: provide text.

subnormal rem inf with UN trap enabled: ACTION Scott: provide text.

Rounding precision. : PASSED - Rounding precision modes SHOULD modify exponent range to mimic base precision. ACTION Darcy: provide text for footnote.

NaN and Infinity in strings : ACTION Darcy: will draft a proposal.

Underflow definition : Hough proposed that the preferred definition SHOULD be - underflow occurs when a non-zero exact result would be smaller in magnitude than the smallest normalized number, independent of rounding mode, independent of the underflow trap enable. (As a new side effect of this definition, a subnormal result could have underflow exception but not inexact. As an old side effect, a result rounded to the smallest normalized number could have underflow and inexact flags attached.) The purpose is to have one preferred simple easy to remember definition of underflow for the benefit of hardware implementers and testers primarily - all the latitudes permitted in 754 have no benefit to end users and have proven to be not worth the cost in verification complexity. The effect is to encourage detection BEFORE ROUNDING in future implementations. IA32 is after rounding; other implementations have varied widely. ACTION Hough: draft a proposal.

754 | revision | FAQ | references