IEEE 754R Meeting April 15, 2004 Raw Minutes
ATTENDEES: Dan Zuras, Matthew Applegate, Eric Schwarz, Mike Cowlishaw,
Michael Parks, Dick Delp, Peter Markstein, David Hough, Jim Thomas, Jeff
Kidder, Jon Okada, Prof. Kahan, Jason Reidy, John Hauser, Joe Darcy
DRAFT REVIEW in morning 10 - 11:40am - Jeff Kidder and David Hough took
SUMMARY OF MEETING:
Only resolutions on NaNs
1) we will not require sign bit propagation on NaN
2) must propagate one of the input QNaNs (no commutativity)
Comebacks for Jeff Kidder:
1) need conversion proposal
2) need to look SNAN and QNaN encodings
3) need language for integer payloads of instruction for NaNs
Also I would like thank ARITHMATICA for hosting the meeting. It was an
excellent facility for having a meeting. Thanks, Matthew and Clem and the
rest of Arithmatica.
DETAILS OF MEETING: (probably more than most people care for, but just in
case details are needed later)
JEFF KIDDER PRESENTED NAN PROPOSAL
discussion on 1xxx being SNaN, this causes problems for quieting, causes
01xxx to be the quieted sNaN
copyQNaN(x) argued on the data type that should be returned,
predicates (sameNaN(x,y)) - question should payload for comparison include
bit separating sNaN from qNaN
Rules of QNaN propagation Proposal A, silent sign bit, B - sign bit is
Quieting an SNaN, - do we want a separate pattern for SNaN vs. a quieted
SNaN vs. a original QNaN
suggested a pattern to indicate no information in NaN payload ...
754 only specifies "should" propagate one of the input QNaNs
Propagating NaNs must be done at high speed, so easy hardware algorithms
if complex, then will be done in software which delays execution
Kahan would like propagation of one of the input NaNs, and would prefer
payload to be instruction address
then if he fixes that one, it should not appear again.
Darcy would like reproducibility of propagation of NaNs, for code debug on
different platforms, and testing
Kahan asked what part to preserve on conversion from Double to Single
Kidder suggested preserving high bits
Schwarz argued for low bits for decimal, and if instruction address
BFP wants to preserve left and DFP wants to preserve right
Further discussion on payload for CopyQNaN
Should the all ones pattern be an SNaN? Hough argued for it ,
Schwarz argued all zeros better if this were a significant argument
Hough argued for SNaN to be eliminated
implementation defined signaling behavior, since can't get traps
Zuras - Proposal to just propagate one of the input QNaNs rather than
strive for Commutativity
MIPS and HP-PA return canonical NaN
microprocessor standards committee wants all normative text in the main
body of text and not an appendix (prefer annex),
Schwarz suggested encoding NaNs with the first bit of fraction equal to
one, Kidder pointed out this produces illegal representations
Hough's proposal of "should" have a trapping NaN with an enablement bit
Kidder wanted to know pattern and what the encoding is, but Hough didn't
want it specified
Zuras asked "will we have traps"?
Hauser said there should a terminating behavior
Hough - No, because non-portability of the environment
Darcy - it is not our job to find uninitialized data. There are better
Zuras proposes - there is set of NaNs called QNaNs and an undefined section
Hough and Darcy want to get rid of SNaNs because not worth their weight
Hauser - should be compatible with old standard except if there is no
audience for function
wants to drop SNaN completely
just SNaN part of invalid exception would be removed.
Hauser - Does any language support SNaN?
C++ was suppose to but definition conflicts with it.
Individual user created own language.
Steve Walther and Bob Fraley of HP Deer Creek Rd insisted on SNaNs in 754.
Kidder suggested stating there are zero or more SNaNs.
Kahan said there was an implementation on an IBM PC in assembler written
using SNaNs for statistical analysis, argued not to remove them
Signalling NaNs do not have to trap to comply with 754
Hough - symbolic links to history (Mary Payne's example) more important
than uninitialized data
Public Comment -
getting a voting list, yeh or nay and why not
decided to review nay arguments as a committee
discussed whether SNaNs should exist at all
Kidder proposed no
argued again whether SNaNs should be used for unintialized data
Reidy - problem applies to more than floating point and should be
solved in general way, Purify tools
Kahan - Acromen function example of program with difficult
Straw vote - Elimination of SNaNs for Upward Conformance - Level 2
8 for - 3 against - 3 abstain
No rational for arguing either way, could easily be reversed
Traps have already been eliminated
Kahan argued for help in debugging programs
Discussion went on to discuss use of Inexact Flag
Kahan "most people who knew how to use it (Inexact Flag) have died."
tricks in using inexact flag, advantage in solving cubic equation,
inexact doesn't require much hardware and doesn't penalize execution
time except for divide
SNaN cost is mainly in terms of complexity of the standard
by making optional it may make language standards simpler
Markstein argued that we should specify that copying does not set off SNaNs
Agreed there are nuisance cases
Schwarz posed question of whether Decimal and Binary should have separate
flags and rounding modes?
Hauser and Kahan agreed that flags should probably only have one set
Kahan stated that rounding modes may want to be separate
Straw Pole on whether signalling NaNs are optional in Level 1 and 2?
6 for - 4 against - 5 abstain
Next meeting May 12-13 Intel, Jeff Kidder
Systems and Technology Group
(845) 435-6413 / T/L 295-6413