Endian-ness of IEEE floating-point hacks

08cd596c9a48bca2065c74b09c653305
0
kwhatmough 101 Aug 09, 2008 at 00:33

In a previous post I refer to one of the well-known IEEE floating-point ‘hacks’ in which you alias (or union) a float and an int so that you can apply integer bit-fiddling tricks which tend to be faster than the equivalent conditional branching.

http://www.devmaster.net/forums/showthread.php?t=12680

In general I _think_ that the IEEE 754 representation is almost ubiquitous these days. However, should one be concerned about potential issues with endian-ness when using a method like this? Apparently the endian-ness of the memory representation is not part of the IEEE specification:
Endianness – Wikipedia (http://en.wikipedia.org/wiki/Endianness#Floating-point_and_endianness)
although I would like to think that the endian-ness of the float representation is consistent with the endian-ness of the corresponding integer representation. Perhaps it is only a potential issue when dealing with (64-bit) doubles and longs, as opposed to (32-bit) float and int(?)

<Assume here that we want the code to be portable at least to PC, Mac, and perhaps the major game consoles>.

1 Reply

Please log in or register to post a reply.

A8433b04cb41dd57113740b779f61acb
0
Reedbeta 168 Aug 09, 2008 at 00:54

Interesting question. I checked this on x86 (Windows) and on Cell (PS3), which is bi-endian but uses big-endian mode by default:

union {
    unsigned char b[8];
    unsigned long long int n;
    double g;
};
n = 0xdeadbeefbaadf00dULL;
printf("%02x %02x %02x %02x %02x %02x %02x %02x\n",
    b[0], b[1], b[2], b[3], b[4], b[5], b[6], b[7]);
g = 3.141592653589793;  // hex value 0x400921FB54442D18
printf("%02x %02x %02x %02x %02x %02x %02x %02x\n",
    b[0], b[1], b[2], b[3], b[4], b[5], b[6], b[7]);

The output for x86:
0d f0 ad ba ef be ad de
18 2d 44 54 fb 21 09 40

For Cell:
de ad be ef ba ad f0 0d
40 09 21 fb 54 44 2d 18

That seems to indicate the floating-point byte order is consistent with the integer byte order.