Notes for the 8/19 meeting of 754R...
The Thursday 8/19/04 draft review meeting of the IEEE 754
revisions group was hosted by David Hough at 1:00 PM in the
Oasis Room in building 16 of the Sun facility in Menlo Park.
In attendence were:
Mike Cowlishaw IBM (phone)
Joe Darcy Sun
Dick Delp Self
Marc Dumas CNRS-INRA
Ivan Godard OOTB
David Hough Sun
Prof Kahan Berkeley
Jeff Kidder Intel (phone)
Alex Liu Sun
Michael Parks Sun
Eric Schwartz IBM (phone)
Jim Thomas HP
Dan Zuras Chairman
We began with the subcommittee work again, more or less at
The need for a boolean that distinguishes between standard &
non-standard decimal numbers was mentioned. (IsCanonical() or
some such thing.) BTW, all one's in a declet is a bad sign.
But, the all ones number is a signalling NaN. The primary issue
was between not wanting to implement the circuits nesessary
detect & report them & not wanting to run software & numbers of
Dave moved to add an IsCanonical() predicate. Seconded &
Back to the larger issue of totalorder. The motion to accept
the totalorder, define minnum & maxnum, et al was moved &
On to Annex Z.
Ivan asked if this makes redundant some specifications in the
rest of the standard. In particular could we use the notation
defined here to describe the rest of the standard. I said it
could be done but I'm not sure it SHOULD be done.
Jim & I had a lengthy discussion that I was not able to take
notes on as I was in the middle of it. (I apologise for that.)
Dave suggested that we might want to define a variable precision
binary arithmetic (together with its descriptor) & require it in
Joe wondered what primitives we might need to support this & he
mentioned the FMA & ternary add as two possible primitives. The
notion being supported by these operations is know as
Marc mentioned that one might also improve things if you could
get easier & faster access to the inexact bit.
Prof Kahan pointed out that the "smaller" large fixed precisions
can use substantially faster algorithms that those that are
required for variable precisions. This suggests one SHOULD
consider those as fixed precisions.
Dave clarified his requirement to variable precision to make it
sound similar to the rest of the standard.
In the end, Annex Z was accepted as something I should continue
to work on but not to be accepted in the text of the standard at
Underflow, formats, correctly rounded base conversion, traps,
modes, et al, are other things that people want us to work on in
A small discussion of traps & flags ensued here.
On to modes.
As could be predicted from the outset, the most controversial
issue associated with modes was the possibility that one might
have to execute code for which the rounding mode is not
determinable until run time.
Naturally, a lengthy & frank discussion ensued.
Jeff mentioned existing machines that predict modes on the fly
much like branches are predicted.
Joe pointed out that, if the primary application of dynamically
changing rounding modes is to debug a piece of code, then the
ability to do this should be confined to a debugger.
Dave said, "What about an Annex D: Desireable Debugging
Devices"? I like that idea. Maybe Annex DDD?
Prof Kahan was uncomfortable with confining this capability to
debuggers largely on the grounds that it is unlikely to happen.
Jeff tried to argue that limiting the change of modes to those
which happen at scope boundaries is fundamentally more limited
in its implications than the implications of changing a global
variable. Ivan asserted that it was not. I'm not sure.
Joe said that the calling convention has to make some statement
about how you use non-default modes in order to determine how
the call & return must work to work correctly.