From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,7b60a2e8329f4e64 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.66.84.100 with SMTP id x4mr1464144pay.43.1358502561979; Fri, 18 Jan 2013 01:49:21 -0800 (PST) Path: s9ni3372pbb.0!nntp.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail From: Stephen Leake Newsgroups: comp.lang.ada Subject: Re: GNAT 4.4.5 Record Bit_Order Endian issues References: <20bda3de-b033-4b4e-8298-2ac47701b814@googlegroups.com> <85hamiulsn.fsf@stephe-leake.org> <85bocoqxis.fsf@stephe-leake.org> <9961f0a1-aa2c-47d5-be84-77e495ea2a0f@googlegroups.com> Date: Fri, 18 Jan 2013 04:49:21 -0500 Message-ID: <85a9s64y8u.fsf@stephe-leake.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (windows-nt) Cancel-Lock: sha1:xg6eC/mtYg0BA7yBT95jnSfXwcg= MIME-Version: 1.0 X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: be95550f91aa1e029e66121901 X-Received-Bytes: 6021 Content-Type: text/plain Date: 2013-01-18T04:49:21-05:00 List-Id: awdorrin 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