[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: convertFormat and signaling NaN



I think it is more useful to have it be a copy.
The instructions that support data movement (load store move) would probably 
want it to be a copy, so they could be used to spill and fill registers with 
arbitrary contents. If it was defined as a convertForamt these architectures 
would likely have to do a multiply by 1.0 to implement the convertFormat 
semantics.
Roger

-----Original Message-----
From: stds-754@xxxxxxxx [mailto:stds-754@xxxxxxxx] On Behalf Of Dan Zuras IEEE
Sent: Sunday, March 13, 2011 5:48 PM
To: Stephen Canon
Cc: stds-754@xxxxxxxx; Dan Zuras IEEE
Subject: Re: convertFormat and signaling NaN

Subject: Re: convertFormat and signaling NaN
From: Stephen Canon <scanon@xxxxxxxxx>
Date: Sun, 13 Mar 2011 16:49:55 -0700
Cc: stds-754@xxxxxxxx
To: Vincent Lefevre <vincent@xxxxxxxxxx>

Vincent --

. . .

For that matter, we were also discussing whether this
requirement of IEEE-754 (convertFormat including same-format
conversions) was a deliberate choice or the result of an
oversight.  At the time of our most recent discussion,
none of us could remember with certainty whether or not
this was deliberate.

I don't presume to speak for the entirety of the C bindings
working group, but I believe that most of us would welcome
any input from this list.

- Steve


        Steven is mostly correct.  This is not so much an
        oversight as an unintended side effect.

        The whole notion of formatOf operations was created
        in 754-2008 to address the language bindings issues
        generated differently by different machines.

        Some architectures (a la 8086 et al) load all operands
        into a subsumptive or nearly typeless register.  In
        this case, double extended.  All operations are carried
        out in this 'type' which has a larger range & precision
        than all supported basic types.  In this case, when a
        result is returned to memory a type conversion (either
        implicit or explicit) of a particular format (thus,
        formatOf) is required to fit the result into the
        desired memory object.

        Other architectures keep track of the type of operands
        & must routinely deal with problems of heterogeneous
        dyadic operations like single + double & the like.
        Such architectures have rules for the type of results
        & may or may not need to convert a result on store.

        Our problem as a standards body was how to correct the
        1985 oversight of not specifying language bindings &
        still support both architectural styles.

        formatOf was part of our solution.

        So, on the one hand we DID spend a lot of time
        considering issues along these lines.  On the other
        hand, I think Steven is correct in that we never
        considered an instance of convert to one's own type
        as anything more serious than a copy.

        This is why I feel you are free to use either
        interpretation in C.

        My personal preference would be to interpret it as
        a copy.  But I would not call your baby ugly if it
        did a null convert.  I suppose you could also support
        the interpretation that a null convert could be a copy
        in the implicit case & a convert in the explicit case.

        Anyone else have a strong opinion on this?

        Yours,

                                   Dan


754 | revision | FAQ | references | list archive