Endian-ness of IEEE floating-point hacks

[kwhatmough]

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>.

[Reedbeta]

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.