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.180.74.79 with SMTP id r15mr3009945wiv.4.1358443734022; Thu, 17 Jan 2013 09:28:54 -0800 (PST) X-FeedAbuse: http://nntpfeed.proxad.net/abuse.pl feeded by 88.191.116.97 Path: i11ni3485wiw.0!nntp.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!nntpfeed.proxad.net!dedibox.gegeweb.org!gegeweb.eu!gegeweb.org!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: GNAT 4.4.5 Record Bit_Order Endian issues Date: Thu, 17 Jan 2013 17:28:52 +0000 Organization: A noiseless patient Spider Message-ID: References: <20bda3de-b033-4b4e-8298-2ac47701b814@googlegroups.com> <85hamiulsn.fsf@stephe-leake.org> <85bocoqxis.fsf@stephe-leake.org> Mime-Version: 1.0 Injection-Info: mx04.eternal-september.org; posting-host="6d11d42385b58e82a68a7c31ea9c32ac"; logging-data="11667"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/J3oEx8ptPYZ/MfrxfW1yJhl8uA+1H7N0=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (darwin) Cancel-Lock: sha1:xsh7XGYs94Zna+ecDbWVjCK13SA= sha1:RTmXIH6reNgwJF6sPQ85EgSdFOY= Content-Type: text/plain Date: 2013-01-17T17:28:52+00:00 List-Id: Stephen Leake writes: > Simon Wright writes: > >> Stephen Leake writes: >> >>> awdorrin writes: >>> >>>> I have a record with specification definition that starts, using big endian notation, with: >>>> >>>> for TRACK_RECORD_TYPE use >>>> record >>>> TRACK_ID at 0 range 0 .. 11; >>>> TRACK_ID_CNT at 1 range 4 .. 9; >>>> ... >>>> >>>> >>>> The meaning being that the first 12 bits hold a track id and the next >>>> 6 bits hold the Count value. >>> >>> If you are allocating consecutive bits, then do this: >>> >>> for TRACK_RECORD_TYPE use >>> record >>> TRACK_ID at 0 range 0 .. 11; >>> TRACK_ID_CNT at 0 range 12 .. 17; >>> ... >> >> I don't see why this makes a difference? > > 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. 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. > The problem is what does "the first twelve bits" mean, when the > "natural" size of a chunk of memory is 8 bits? > > In this code: > > TRACK_ID at 0 range 0 .. 11; > TRACK_ID_CNT at 1 range 4 .. 9; > > if Storage_Unit = 8, the two fields overlap. I can't figure out a > storage arrangement that makes these fields contiguous; can you draw a > picture? Changing to a compiler/target with a different Storage_Size > changes the meaning. Certainly a different Storage_Size would screw things up. But which processor in actual common use - that you're likely to want to interoperate with - doesn't use 8? If you were using a PowerPC, the layout would be Byte 00000000111111112222222233333333 Bit 01234567012345670123456701234567 Element AAAAAAAAAAAABBBBBB-------------- What's so hard about that? 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." and in the next para "Consequently, the notion of a range of bits only makes sense with respect to a machine scalar." > 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' and try hard to ensure that fields aren't split across word boundaries. And I would write field positions in terms of bit offsets from the 'word'. I think I'm agreeing with you here! > 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.