Hi, I ran across an annoying problem: Floating point values have endianness issues as well, and fp and integer endianess can differ... So I came up with a patch for bswap.h (only for float and double, as I don't really know about long double). But at least a configure patch is still needed... Any suggestions? Please? Greetings, Reimar Döffinger
On Tue, 22 Feb 2005 17:34:23 +0100, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> said: I ran across an annoying problem: Floating point values have endianness issues as well, and fp and integer endianess can differ...
On which systems does fp and integer endianess differ? Is it in the CPU or the compiler (e.g. stupidity with uint64_t)? __Martin
Martin Simmons wrote: [ Charset ISO-8859-1 unsupported, converting... ]
On Tue, 22 Feb 2005 17:34:23 +0100, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> said: I ran across an annoying problem: Floating point values have endianness issues as well, and fp and integer endianess can differ...
On which systems does fp and integer endianess differ? Is it in the CPU or the compiler (e.g. stupidity with uint64_t)?
I think the definition of little-endian float is that the MSB of the first byte is the sign, the exponent is in the first bytes, and the least significant part of the mantissa is the last byte. Big endian is the same but byte-reversed. AFAIK, most systems use little-endian float, except, strangely, x86, which uses little-endian float. The result is that if you load a float value as an int, the sign of the int will be the same as the sign of the float and the LSB of the int will be the LSB of the mantissa. liba52 uses this to convert float to int, so if you can play ac3 with mplayer, then float and int endianness matches (or mismatches, depends how do you look at it). The platforms I have access to and I've tested are: Sparc, hppa, PowerPC are all big-endian int, little-endian float x86 is little-endian int, big-endian float. Test: union { float f; int32_t i; } fi; fi.f = 384.0 printf("0x%x\n", fi.i); This prints 0x43c00000 on all the above 4 platfrms. Zoli
On Sun, 6 Mar 2005 14:59:46 -0600 (CST) Zoltan Hidvegi <mplayer@hzoli.2y.net> wrote:
AFAIK, most systems use little-endian float, except, strangely, x86, which uses little-endian float.
Interesting... That first one was probably supposed to be "big-endian".
On Sun, Mar 06, 2005 at 02:59:46PM -0600, Zoltan Hidvegi wrote:
I think the definition of little-endian float is that the MSB of the first byte is the sign, the exponent is in the first bytes, and the least significant part of the mantissa is the last byte.
That's the definition of the big-endian float.
Sparc, hppa, PowerPC are all big-endian int, little-endian float x86 is little-endian int, big-endian float.
What you call little-endian float is big-endian and vice versa. I'm not familiar with hppa, but Sparc, PowerPC and x86 use the same endianness for both int and float. As do all the other architectures I'm familiar with. -- Ville
Ville Saari wrote:
On Sun, Mar 06, 2005 at 02:59:46PM -0600, Zoltan Hidvegi wrote:
I think the definition of little-endian float is that the MSB of the first byte is the sign, the exponent is in the first bytes, and the least significant part of the mantissa is the last byte.
That's the definition of the big-endian float.
Maybe. That would seem to be logical for me, but I've read somewhere that it's the opposite. But the term we use to call it does not really matter as long as we agree on the layout. Zoli
On Sun, 6 Mar 2005 14:59:46 -0600 (CST), Zoltan Hidvegi <mplayer@hzoli.2y.net> said: Martin Simmons wrote: [ Charset ISO-8859-1 unsupported, converting... ]
> On Tue, 22 Feb 2005 17:34:23 +0100, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> said: I ran across an annoying problem: Floating point values have endianness issues as well, and fp and integer endianess can differ...
On which systems does fp and integer endianess differ? Is it in the CPU or the compiler (e.g. stupidity with uint64_t)?
I think the definition of little-endian float is that the MSB of the first byte is the sign, the exponent is in the first bytes, and the least significant part of the mantissa is the last byte. Big endian is the same but byte-reversed. AFAIK, most systems use little-endian float, except, strangely, x86, which uses little-endian float. The result is that if you load a float value as an int, the sign of the int will be the same as the sign of the float and the LSB of the int will be the LSB of the mantissa. liba52 uses this to convert float to int, so if you can play ac3 with mplayer, then float and int endianness matches (or mismatches, depends how do you look at it).
The platforms I have access to and I've tested are:
Sparc, hppa, PowerPC are all big-endian int, little-endian float x86 is little-endian int, big-endian float.
Test:
union { float f; int32_t i; } fi;
fi.f = 384.0 printf("0x%x\n", fi.i);
This prints 0x43c00000 on all the above 4 platfrms.
Right, that's what I've seen on a variety of other platforms too. Doing some more research, it looks like *some* ARM systems have an issue with word endianness of doubles, i.e. the order of the two 32 bit halves rather then the order of the bytes in the halves. http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=2046/1 http://sources.redhat.com/ml/crossgcc/2003-06/msg00060.html (though I think the latter post has muddled up the byte order, possibly because they are talking about a cross compiler). Here is another test case: union { double f; struct { int32_t i1, i2; } i; } fi; fi.f = 1.0; printf("0x%08x 0x%08x\n", fi.i.i1, fi.i.i2); Typical little endian result: 0x00000000 0x3ff00000 Typical big endian result: 0x3ff00000 0x00000000 __Martin
Martin Simmons wrote:
On which systems does fp and integer endianess differ? Is it in the CPU or the compiler (e.g. stupidity with uint64_t)?
pdp-11 and VAX. Boh, IIRC, used little-endian integers and middle-endian (as in big-endian pair of little-endian 16 bits words) FPs. -- Romain Dolbeau <romain@dolbeau.org>
participants (6)
-
Martin Simmons -
R C -
Reimar Döffinger -
Romain Dolbeau -
Ville Saari -
Zoltan Hidvegi