Re: Is this a GNAT bug???

[nickroberts@blueyonder.co.uk (Nick Roberts)]

On Thu, 02 May 2002 08:56:53 -0500, Mark Johnson
<mark_h_johnson@raytheon.com> wrote:

>> 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.

I wasn't trying to show values as loaded into registers, Mark. I was
trying to show the difference in the ways in which big-endian and
little-endian machines store their integers in memory. The Bit?H/L
rows were intended to show the bit numberings of the data as it would
be numbered if loaded from memory into a register (8, 16, or 32-bit). 

As you infer, big and little-endianness is about both bit numbering
and byte ordering; I was trying to demonstrate the difference in byte
ordering as well as the difference in bit numbering.

The reason why I wanted to show the in-memory representation of 16 and
32-bit integers, as well as 8-bit ones (bytes), is because for some
machines (or Ada implementations) Streams.Stream_Element'Size could be
16 or 32 bits (rather than 8). Since the issue of endianness is most
likely to affect those doing stream-oriented I/O of a record type, the
way a 16 or 32-bit stream element is stored in memory is likely to be
of significance.

For those who may be wondering, Streams.Stream_Element'Size could of
course be something other than 8, 16, or 32. But then on such a
machine the issue of being big-endian or little-endian is irrelevant
(as the machine will be neither).

Note that the diagrams of both Mark and myself assume a storage
element size of 8 bits. If this is 16 or 32 bits, different diagrams
would be more appropriate.

Big endian (System.Storage_Size=16, Bit_Order=High_Order_First)
SE      0000000000000000 1111111111111111 ...
Bit16VH 1111110000000000 1111110000000000 ...
Bit16VL 5432109876543210 5432109876543210 ...
Bit16H  0000000001111111 0000000001111111 ...
Bit16L  1234567890123456 1234567890123456 ...
Bit32H  0000000001111111 1112222222222233 ...
Bit32L  1234567890123456 7890123456789012 ...
Ind     0000000000111111 1111222222222233 ...
-ex     0123456789012345 6789012345678901 ...

Little endian (System.Storage_Size=16, Bit_Order=Low_Order_First)
SE      0000000000000000 1111111111111111 ...
Bit16VH 1111110000000000 1111110000000000 ...
Bit16VL 5432109876543210 5432109876543210 ...
Bit16H  1111110000000000 1111110000000000 ...
Bit16L  5432109876543210 5432109876543210 ...
Bit32H  1111110000000000 3322222222221111 ...
Bit32L  5432109876543210 1098765432109876 ...
Ind     1111110000000000 3322222222221111 ...
-ex     5432109876543210 1098765432109876 ...

Big endian (System.Storage_Size=32, Bit_Order=High_Order_First)
Bit32VH 33222222222211111111110000000000 ...
Bit32VL 10987654321098765432109876543210 ...
Bit32H  00000000011111111112222222222233 ...
Bit32L  12345678901234567890123456789012 ...
Ind     00000000001111111111222222222233 ...
-ex     01234567890123456789012345678901 ...

Little endian (System.Storage_Size=32, Bit_Order=Low_Order_First)
Bit32VH 33222222222211111111110000000000 ...
Bit32VL 10987654321098765432109876543210 ...
Bit32H  33222222222211111111110000000000 ...
Bit32L  10987654321098765432109876543210 ...
Ind     33222222222211111111110000000000 ...
-ex     10987654321098765432109876543210 ...

Finally, I believe big-endian bit numbering conventionally starts from
1 (rather than 0), and I wanted to show this. (Of course, this is only
a convention. I think it is widespread, but certainly not universal.
The PowerPC is normally big-endian as regards byte ordering, but the
IBM documentation numbers the bits from 0 for the LSB to 31/63 for the
MSB; the situation is further confused by some PowerPCs being able to
operate in little-endian mode!)

But this can be a confusing subject, and (as I've proved several times
on comp.lang.ada) I'm not exactly immune to error. I hope the above
makes sense, but please say if it doesn't!