Re: GNAT 4.4.5 Record Bit_Order Endian issues

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

awdorrin <awdorrin@gmail.com> writes:

> The code in question was originally developed on a Motorola (Big
> Endian) CPU, So, given the Motorola 'Bit Order' being
> 'High_Order_First':
>
> Byte: 0        1        2        3
> Bits: 01234567 01234567 01234567 01234567
>
>       00000000 00111111 11112222 22222233
>       01234567 89012345 67890123 45678901
>      
> For a picture using the definition of:
>  TRACK_ID at 0 range 0 .. 11;
>  TRACK_ID_CNT at 1 range 4 .. 9;
>
> Track Id starts at 'Byte 0, Bit 0 and extends to the 11th bit'
>
> Byte:|0       |1        |2
> Bits:|01234567|0123 4567|01234567
>      |00000000|0011 1111|11112222
>      |01234567|8901 2345|67890123
>      |Track ID     |
>               |0000 0000 00|11111|
>               |0123 4567 89|01234|
>                    |Track  |
>                    |Id Cnt |

I see. I guess I never tried to write rep specs this way; I've always
implicitly used the machine scalar concept.

>> In this code: 
>>       TRACK_ID     at 0 range  0 .. 11;
>>       TRACK_ID_CNT at 0 range 12 .. 17;
>>
>> it's obvious that the fields are contiguous, and it's up to the compiler
>> to ensure that happens.
>
> I agree that this notation makes more sense, given Big Endian
> notation. But the question I have is, when can you start at a byte
> other than 0?

When the field you are describing starts on a byte boundary.

More precisely, on a Storage_Unit boundary.

> As I just discovered after upgrading my system from Debian 6/GNAT
> 4.4.5 to Debian 7/GNAT 4.6; the GNAT 4.6 compiler produces the
> overlaps' error messages and will not compile.

It doesn't help that only very recent versions of GNAT get this right.

> Now, if the standard wants to say 'all data fields that span a group
> of bytes must be defined from the same starting byte', that would make
> sense to me.

Yes, that is what it should say. I agree the ARM is very deficient in
descibing this. It really needs to say what Cohen's paper says.

13.5.1(3) says:

     component_clause ::=
         component_local_name at position range first_bit .. last_bit;

But I could find no definition of "position"!

> For example:
>     TRACK_ID     at 0 range  0 .. 11;
>     TRACK_ID_CNT at 0 range 12 .. 17;
>     VAR1         at 0 range 18 .. 20;
>     VAR2         at 0 range 21 .. 23;

that's a 24 bit machine scalar

>     Byte1        at 3 range  0 .. 7;

that's an 8 bit machine scalar

>     Int32Var     at 4 range  0 .. 31;

that's a 32 bit machine scalar

> As for the 'A Proposal for Endian-Portable Record Representation
> Clauses' document, I take the proposal to mean that we should be
> defining the records as a multiple of a 'machine scalar' - which the
> document states could be 8-bit, 16-bit or 32-bit.

The size of the machine scalar is flexible, it does not have to be the
same thru-out the record.

> After further thought, I understand this to mean that our record
> definitions should fit the least common multiple that fits the span.

That does make things simpler, but it is not required.

> So, given my above example, defining 'Byte1' at starting at byte 3,
> would be wrong, since the first 'group' is 3 bytes (24-bits) and
> instead should be an even multiple (ie. 32-bits), so:
>
>     TRACK_ID     at 0 range  0 .. 11;
>     TRACK_ID_CNT at 0 range 12 .. 17;
>     VAR1         at 0 range 18 .. 20;
>     VAR2         at 0 range 21 .. 23;
>     Byte1        at 0 range 24 .. 31;
>     Int32Var     at 4 range  0 .. 31;

I would probably write it this way, since it is a little easier to
understand.

> I would assume, that if the record needed the 'Byte1' and 'Int32Var'
> elements swapped physically that the definition would need to be
> bumped from a '32-bit' base, to a 64-bit base:
>
>     TRACK_ID     at 0 range  0 .. 11;
>     TRACK_ID_CNT at 0 range 12 .. 17;
>     VAR1         at 0 range 18 .. 20;
>     VAR2         at 0 range 21 .. 23;
>     Int32Var     at 0 range 24 .. 55;
>     Byte1        at 0 range 56 .. 63;
>     Int32Var2    at 8 range  0 .. 31;

That is correct, but not necessary, since Int32Var starts on a byte
boundary. And some compiler might support only 32 bit machine scalars.

> While I understand the rationale of defining the records using this
> methodology, it requires that the programmer knows that the 'starting
> byte' has restrictions.

And the ARM does not help.

> Rather than put this expectation on the programmer, it seems like
> something best left to the compiler to work out.

As Cohen's paper makes clear, the compiler _can_ work it out, but
without the notion of machine scalar, the notation is ambiguous.

> So if I write 'Track_ID_Cnt at 1 range 4 .. 7' the compiler should be
> able to translate that for me to: 'Track_Id_Cnt at 0 range 12 .. 17'
> (etc)

I don't think so, since that '4' is not on a byte boundary.

This is related to the confusion between bit endianness and byte
endianness; they are _not_ the same thing, although they almost always
are correlated. See my other post.

-- 
-- Stephe