Re: Endianness and Record Specification

[Robin Vowels <robin.vowels@gmail.com>]

On Sep 22, 4:16 am, awdorrin <awdor...@gmail.com> wrote:
> I have been reading over google searches all day and I feel like I'm missing something here.
>
> Is there a straight forward method to use Standard'Default_Bit_Order to define a specification for a record, that will work on either a Little Endian or Big Endian system?
>
> For instance, I have a 16-bit field that is comprised of 5 bit-fields:
> Reserved:     1 bit
> Error Flag:   1 bit
> Word Count:   6 bits
> Bus Id:       1 bit
> Message Type: 7 bits
>
> So, 0x0401 is [0000 0100 0000 0001] or [0][0][000100][0][0000001]
> Word Count = 4, Message Type = 1
>
> On a Big Endian system the record is defined as:
>
> type TW_REC is record
>   Message   : Integer;
>   BusId     : Integer;
>   WordCount : Integer;
>   Error     : Integer;
>   Reserved  : Integer;
> end record
> for TW_REC use record
>   Reserved  at 0 range 0..0;
>   Error     at 0 range 1..1;
>   WordCount at 0 range 2..7;
>   BusId     at 1 range 0..0;
>   Message   at 1 range 1..7;
> end record;
>
> Now, I know I can rewrite this on a Little Endian system to:
> for TW_REC'Bit_Order use System.High_Order_First;
> for TW_REC use record
>   Reserved  at 1 range 0..0;
>   Error     at 1 range 1..1;
>   WordCount at 1 range 2..7;
>   BusId     at 0 range 0..0;
>   Message   at 0 range 1..7;
> end record;
>
> Taking advantage of the High_Order_First flag to keep the bit ordering the same,
> but is there a way to either calculate the byte position, or 'conditionally compile' the right record specification, depending on the system on which it is being compiled?
>
> At first I was thinking I could do:
>
> if Standard'Default_Bit_Order = 1 then
>   -- defined Little endian rec spec
> else
>   -- define Bit endian rec spec
> end if;
>
> But, the compiler doesn't let me do that... :-)
>
> I would think I should be able to somehow use the
> Default_Bit_Order to define some sort of relative byte position,
> depending on the system endianness, but I'm drawing a blank
> and hoping someone might have a quick example they could provide.

This won't help your problem, but
PL/I bit strings are stored in correct order regardless
of big-endian or little-endian machine on which the program runs.
The memory image is identical for both machine types.