Re: convertFormat and signaling NaN
On 2011-03-13 17:47:46 -0700, Dan Zuras IEEE wrote:
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
If you allow the C implementation to have an extended precision for
results of expressions, this is no longer a copy, but a conversion
between different formats. In
double x, y;
/* ... */
y = x;
x already has this extended type. BTW, that's why 1 * x and x are
equivalent, ignoring signaling NaN's (F.8.2).
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)