Re: GNAT 4.4.5 Record Bit_Order Endian issues

[awdorrin <awdorrin@gmail.com>]

On Thursday, January 17, 2013 5:16:36 PM UTC-5, awdorrin wrote:
> This is why I thought the Bit_Order flag was used to fix.
> 
> On Intel, using Bit_Order = System.High_Order_First,
> I would have expected to see: 0xcb 0xa0

I had a realization in the shower this morning:

The byte and bit ranges used in the specification clause is not describing memory locations, it is describing the location in the CPU register. The Bit_Order flag is being used to describe which end of the CPU register is bit zero.

So the 'machine scalar' term that was being used earlier is really refering to the size of the memory access used to load the register.

Due to the (byte level) endian differences, it would seem that it is not possible to describe the physical bit locations in memory, since it is the offset in the register that is being described.

In order to get the record memory contents ordered the way I want them to be, I'm going to have to play some byte swap games and translate the record memory contents into a 'big endian buffer'. 

Presumably, if the record contents can be defined in terms of a 32-bit 'machine scalar' - then this endian conversion can be done by starting at 'MyTrkRec'Address' and doing byte swaps on 4-byte (32-bit) groupings.

In C I'd simply make a 'uint32_t' pointer to the record address, and loop through till the end of the record doing 'htonl()' calls. But Ada doesn't make things quite so 'easy' ;-)

Fixing poorly designed legacy code is really not my favorite thing to do...