On Tue, Jan 30, 2007 at 10:49:02AM -0500, Robert Dewar wrote:
> Paul Schlie wrote:
>
> >- as trap representation within the context of C is a value
> >representation which is not defined to be a member of a type, where if
> >accessed or produced evokes undefined behavior; so admit as to the best of
> >my knowledge all potentially enclosable values for IEEE floats and doubles
> >are defined, it would seem trap representations don't exist in typical fp
> >implementations, as such an implementation would require more bits of
> >encoding than the type itself requires.
>
> You don't think a signalling NaN is a trap value?
I do.
> The existence of
> such values (which do indeed cause a trap if loaded),
If loaded? This is a very approximate description.
For all architectures I use, it is rather "if used as an operand
of an arithmetic instruction", but the values can be copied
around without ever generating a trap. Even negating or taking
the absolute value never traps since those are not considered
"arithmetic" instructions.
And even then you have to explicitly enable the trap for invalid
operation (on systems using IEEE754), otherwise it is simply
propagated as a QNaN.
I remember that the VAX had separate instructions for moving floats
and ints (of the same size) and the only difference between them was
that move floating point instruction would trap on the "reserved
operand" value (zero exponent and sign bit set). However compilers
did not actually use the floating point move instructions (probably
for performance reasons).
Gabriel
