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.