Related articles |
---|
Floating point endian issue tomb@microware.com (Tom Brasier) (1996-10-24) |
Re: Floating point endian issue mcintosh@bellcore.com (1996-10-25) |
Floating point endian issue dave@occl-cam.demon.co.uk (Dave Lloyd) (1996-10-25) |
From: | mcintosh@bellcore.com (Allen Mcintosh) |
Newsgroups: | comp.compilers |
Date: | 25 Oct 1996 22:09:46 -0400 |
Organization: | Bellcore, Morristown NJ |
References: | 96-10-123 |
Keywords: | architecture, arithmetic |
Tom Brasier <tomb@microware.com> wrote:
>On a big endian machine, I might declare two constants as so
>
>_value dc.l 0x01234567,0x89abcdef
>
>On a little endian machine, I can have either...
>_value dc.l 0x67452301,0xefcdab89
>-or-
>_value dc.l 0xefcdab89, 0x67452301
The answer (on a DECstation - little-endian MIPS chip) is "none of the above":
_value dc.l 0x89abcdef,0x01234567
I ran the following as a test:
#include <math.h>
main() {
union { double d; int i[2]; }ch;
ch.d = 4.0 * atan(1.0);
printf("pi = %.16f = 0x%08x 0x%08x\n", ch.d, ch.i[0], ch.i[1]);
}
On a SPARC, I get this:
pi = 3.1415926535897931 = 0x400921fb 0x54442d18
and on a DECstation, I get this:
pi = 3.1415926535897931 = 0x54442d18 0x400921fb
This is consistent - bytes get stuffed into FP registers in order from
the least significant bits to the most significant bits and the exponent.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.