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.72.232 with SMTP id g8mr1259319pav.23.1358502981178; Fri, 18 Jan 2013 01:56:21 -0800 (PST) Path: s9ni4339pbb.0!nntp.google.com!npeer01.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> Date: Fri, 18 Jan 2013 04:56:20 -0500 Message-ID: <85622u4xx7.fsf@stephe-leake.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (windows-nt) Cancel-Lock: sha1:lE2M+Q9I2rBNgr2gVJIeCjakYcE= MIME-Version: 1.0 X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: 07f7c50f91c45e029e66123155 X-Received-Bytes: 3736 Content-Type: text/plain Date: 2013-01-18T04:56:20-05:00 List-Id: Simon Wright writes: > Stephen Leake writes: > >> The best explanation I have seen is in >> http://www.ada-auth.org/ai-files/grab_bag/bitorder.pdf >> >> That introduces the concept of "machine scalar", which helps a lot. > > What that paper leads _me_ to decide is that I will never tell the > compiler to use the non-default bit order. (I have a feeling that Dmitry > would agree with me). The compiler may get it "right", but I don't trust > myself to. It is like learning a new language; it takes a while to get comfortable with it. And you need a compiler that gets it right :). > I had stupidly thought that 'use the non-default bit order' would mean > 'within ths declaration, behave as though you are on an other-endian > machine'. OP's original declaration worked just fine on the big-endian > machine it was written for. That is confusing bit endianness with byte endianness; they are not the same thing, and the ARM does not make it clear. See my other post. > And I'm not sure that the Cohen paper isn't begging the question - in > "Avoiding noncontiguous bit fields" on p7 he says > > "Although bits in different bytes may correspond to adjacent bits in > a machine scalar (i.e., the bits become adjacent when loaded into a > register), there is no notion of two bits in different bytes of > memory being adjacent." Pointing out the difference between bit and byte endianness (it would help if he had said that explicitly). > and in the next para > > "Consequently, the notion of a range of bits only makes sense with > respect to a machine scalar." One of the features of 'machine scalar' is that it allows you to ignore byte endianness while deciphering a record rep spec. >> 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 would expect the engineer defining the interface to use 16- or 32-bit > 'words' replace 'words' with 'machine scalar', and you've got it. 'words' has always been a fuzzy concept; 'machine scalar' is much crisper. > and try hard to ensure that fields aren't split across word > boundaries. Exactly. Because otherwise the meaning is ambiguous. > And I would write field positions in terms of bit offsets from the > 'word'. I think I'm agreeing with you here! Yes. >> Why do you say this is buggy? > > I now see that GNAT (well, recent GNATs) are behaving according to the > spec. So what I'm saying is that I think the spec (ie, the ARM) is > buggy. At the very least it could say HERE BE DRAGONS. Yes, the ARM is deficient (I don't think it's actually wrong, just not as clear/helpful as it could be). -- -- Stephe