Notes for the 8/19 meeting of 754R...

[r754@xxxxxxxxxxxxxx]

        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
        random.

        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
        dubius origin.

        Dave moved to add an IsCanonical() predicate.  Seconded &
        passed.

        Back to the larger issue of totalorder.  The motion to accept
        the totalorder, define minnum & maxnum, et al was moved &
        seconded.  Accepted.

        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
        some sense.

        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
        distillation.

        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
        this time.

        Underflow, formats, correctly rounded base conversion, traps,
        modes, et al, are other things that people want us to work on in
        the subcommittee.

        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.