Byte endianess vs Bit endianess

[John Darrington]

Further to my discussions with Jos?? on IRC ...

Perhaps there needs to be some more powerful way of dealing with
situations where byte-endianess is distinct from bit-endianess.  As
Jos?? says bit-endianess is (almost) always big endian.  That is to
say, that the MSB of a byte appears earlier in memory than the LSB (it
would be an unusual machine which did it the other way around, but who
knows ...) 

If the byte-endianess is the same as the bit-endianess (ie big-endian)
there is no problem. However in the little endian case, things get
messy when dealing with bit fields which do not start/end on byte
boundaries.  

This raised its ugly head in the context of implementing  ieee754
floating point numbers. Consider a C program fragment: 

extern FILE *fp
double dp = -100;
fwrite (&dp, sizeof dp, 1, fp);

This writes a double precision floating point number to a file.  On a
big-endian machine, it'll appear in the file as: 

C059 0000 0000 0000 0000

and this can be easily parsed using the Poke fragment

deftype ieee754_double = struct
{
  int<1>  sign;
  int<11> exponenent;
  int<52> fraction;
};

(ieee754_double @ NULL)

Here sign=1 (the MSB of C0), and exponent is 0x405 (the lower 7 bits
of C0 juxtaposed with the upper four bits of 59).
fraction=9 0000 0000 0000 0000 
This means, - 1.10010000000000000000 (base2) x 2^6 == -100 base10  ---  No
problem. 


However, on a little endian machine, the C program above will write:

0000 0000 0000 59c0

Now it would be tempting to think that poke can parse this with

deftype ieee754_double = struct
{
  little int<52> fraction;
  little int<11> exponenent;
  little int<1>  sign;
};

But that gives a totally wrong parse:

fraction=0x5000000000000
exponent=0x074
sign=0


So it seems that IOS needs to be a bit more intelligent when dealing
with little-endianess?  In particular, it needs to be aware that
whilst bytes might be ordered little endian, the bits within each byte
remain big-endian.

J'