: Re: [MPlayer-dev-eng] Flaoting point endianness??

[Martin Simmons]

>>>>> On Sun, 6 Mar 2005 14:59:46 -0600 (CST), Zoltan Hidvegi <mplayer at 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 at 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