Re: GNAT 4.4.5 Record Bit_Order Endian issues

[Stephen Leake <stephen_leake@stephe-leake.org>]

awdorrin <awdorrin@gmail.com> writes:

> Given the previous definition, the mapping to memory is not what I am
> expecting. (Which is why I thought I needed the Bit_Order =
> System.High_Order_First)
>
> Given: TRACK_ID_X at 0 range 0 .. 11;
>
> MyTrkRec.Track_Id_X = 2748; -- 0xabc
>
> Using GDB to debug and print the byte values:
> On a little endian system, I get: 0xcb 0x0a
> On a big endian system, using the original code, I get: 0xab 0xc0
>
> Now, I expect the numbers to be reordered, due to the endian
> differences.
>
> On Intel, using Bit_Order = System.High_Order_First,
> I would have expected to see: 0xcb 0xa0

There are two different kinds of "endianness"; bit endianness, and
byte endianness. 

"bit endianness" is about how to interpret the bit numbers in record rep
specs.

"byte endianness" is about how bytes are ordered in memory

Cohen's paper, and the Bit_Order attribute, only address bit endianness,
not byte endianness.

So if you are writing a multi-byte field to a machine register, or to a
network stream, you need to do byte swapping; Bit_Order does not affect
that. 

> This is why I thought the Bit_Order flag was used to fix.

That is a common misconception. And the ARM is not clear here.

-- 
-- Stephe