Re: GNAT 4.4.5 Record Bit_Order Endian issues

[awdorrin <awdorrin@gmail.com>]

So, I think I figured out how to solve my problem.

Within the legacy code, the representation clause was used to define the memory locations, then the record was being copied to/from a buffer via an imported 'memcpy' call. It worked since the system was Big Endian, but obviously it is non-portable to a Little Endian system.

What I realize now is, if I define the record using 'Bit_Order = System.High_Order_First; and then define the record elements in terms of a chosen machine scalar type (ie. 32-bit)

Now, the record specification will define 'equivalent' record structures, when endian swapping is taken into account.

The following code is probably not the most elegant way to solve this (and I'm open to suggestions) but here it is:

if Standard'Default_Bit_Order = BIG_ENDIAN then
  -- legacy big endian byte copy
  MEMCPY( Target => Track_Address, Source => Track_Rec'Address, Size => Track_Rec'Size/8);
else
  -- little endian convert to big endian by 32-bit word
  declare
    type EndCvtArray is array(UInt32 range <> ) of UInt32;
    WrdCnt : constant UInt32 := Track_Rec'Size/32;
    Target : EndCvtArray(1..WrdCnt);
    for Target'Address use Track_Address; -- overlay
    Source : EndCvtArray(1..WrdCnt);
    for Source'Address use Track_Rec'Address; -- overlay
  begin
    for i in 1..WrdCnt loop
      Target(i) := SwapUInt32(Source(i));
    end loop;
  end;
end if;

function SwapUIn32 is new GNAT.Byte_Swapping.Swapped4(UInt32);

I'm guessing there might be some cleaner way to do this, perhaps using Stream IO. But I tried the code and it appears to work.

Once I understood that the representation clause wasn't defining the memory locations, this made a lot more sense.