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

[Zoltan Hidvegi]

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.

Zoli