Re: GNAT 4.4.5 Record Bit_Order Endian issues

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

awdorrin <awdorrin@gmail.com> writes:

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

Yes, I agree :)

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

That's what I do, but I use my own byte_swap package (which I believe I
wrote before GNAT.Byte_Swapping was available).

My code doesn't use address overlays, but that means it makes copies on
the stack. For small data packets, this is not a problem.

-- 
-- Stephe