On Wed, 01 Feb 2012 10:58:12 +0100, Don Clugston <d...@nospam.com> wrote:
On 01/02/12 09:44, dennis luehring wrote:
The behaviour of the sign bit is completely specified in the x86
manuals. As that link says, the C standard got it wrong in a couple of
places.
The one thing which is implementation specific is that on Intel, an 80
bit load of a signalling NaN doesn't raise an exception, whereas it
does
on AMD. I don't know what Via does.
just a question:
would it be a good idea to test this platform specific behavior
in the phobos unit-tests?
produce "an 80 bit load of a signalling NaN"
check:
intel: do not raise
amd: do raise
via: ...
maybe only for showing that D is aware of this special cases?
It doesn't matter very much. If you load, and then do any operation
(such as add) you'll get an exception. AMD will trigger one instruction
earlier.
Hardly anybody knows this -- I haven't found any references to it. It's
in wikipedia, but the entry that mentions it was written by me!
There is an underlying problem we have though. What _is_ T.init?
If a variable of type T is default initialized as "this is
uninitialized", what is T.init?
In most cases, the compiler should give you a "variable XXX is used
before set" error anyway.
"long double val = NAN;"
This is sNaN for Clang and qNaN for GCC.
--------------
At least on my Intel loading a sNaN and storing it in a double adds a sign.
--------------
import std.stdio, std.math;
void main()
{
ubyte[10] snan = [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40,
0xFF, 0x7F];
ubyte[10] qnan = [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC0,
0xFF, 0x7F];
real srval = 0, qrval = 0;
double sdval = 0, qdval = 0;
asm
{
fld real ptr snan[RBP];
fst double ptr sdval[RBP];
fstp real ptr srval[RBP];
fld real ptr qnan[RBP];
fst double ptr qdval[RBP];
fstp real ptr qrval[RBP];
}
writefln("%s %s %s %s", srval, signbit(srval), sdval, signbit(sdval));
writefln("%s %s %s %s", qrval, signbit(qrval), qdval, signbit(qdval));
}
--------------
nan 0 nan 1
nan 0 nan 0
