Re: Is this a GNAT bug???

[Mark Johnson <mark_h_johnson@raytheon.com>]

Nick Roberts wrote:
> 
> On Tue, 30 Apr 2002 16:55:53 -0500, Mark Johnson
> <mark_h_johnson@raytheon.com> wrote:
> [both examples snipped]
> 
> Am I actually correct?

I believe so, but I am not sure what you are trying to show with your
examples - the values as loaded into a register? I was showing the in
memory representation of the data for the two byte orders. Note that it
takes different code to solve the "equivalence problem" for in memory
and in register representations.

If you were trying to show the in register data (as an 8, 16, and 32 bit
value) I suggest a different layout of the data to make it more clear to
the reader. Something like...

Big endian (Bit_Order == System.High_Order_First)
16 bit value...
Byte 00000000 11111111
Bit  01234567 01234567
Ind  00000000 00111111
-ex  01234567 89012345

32 bit value...
Byte 00000000 11111111 22222222 33333333
Bit  01234567 01234567 01234567 01234567
Ind  00000000 00111111 11112222 22222233
-ex  01234567 89012345 67890123 45678901

Little endian (Bit_Order == System.Low_Order_First)
16 bit value...
Byte 11111111 00000000 
Bit  76543210 76543210
Ind  11111100 00000000
-ex  54321098 76543210

32 bit value...
Byte 33333333 22222222 11111111 00000000 ...
Bit  76543210 76543210 76543210 76543210 ...
Ind  33222222 22221111 11111100 00000000 
-ex  10987654 32109876 54321098 76543210 

Which more clearly shows that the bytes are swapped when the data from
memory is loaded into a register and shows the relative position (2^n as
you described) of each bit within the 16 or 32 bit value. For example,
on a big endian machine index 0 is the most significant bit and on a
little endian machine it is the least significant bit.

For problems where you interface with C programs - values are often
represented in header files as bits shifted so this way of looking at
the problem is often better. However, many Ada programs must be able to
read a stream of bytes and manipulate the data in those streams. In
those cases the in memory way of looking at the problem tends to be
better.
  --Mark