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: a07f3367d7,7b60a2e8329f4e64 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.83.2 with SMTP id m2mr1706181wiy.0.1358654442172; Sat, 19 Jan 2013 20:00:42 -0800 (PST) Path: i11ni8359wiw.0!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.131.MISMATCH!xlned.com!feeder3.xlned.com!border5.a.newsrouter.astraweb.com!border6.newsrouter.astraweb.com!news.astraweb.com!border5.newsrouter.astraweb.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nrc-news.nrc.ca!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx01.iad01.newshosting.com!newshosting.com!69.16.185.11.MISMATCH!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> Date: Wed, 16 Jan 2013 22:49:31 -0500 Message-ID: <85bocoqxis.fsf@stephe-leake.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (windows-nt) Cancel-Lock: sha1:eSDITR8HLyXi14jD9sbhyzaYzlE= MIME-Version: 1.0 X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: 5614d50f774cce029e66101689 X-Received-Bytes: 3419 Content-Type: text/plain Date: 2013-01-16T22:49:31-05:00 List-Id: 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. 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. 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. Note that gnat agrees with me: > OP's way: > awdorrin.ads:13:26: info: reverse bit order in machine scalar of length 16 > awdorrin.ads:13:26: info: little-endian range for component "Track_Id" is 4 .. 15 > awdorrin.ads:15:06: component "Track_Id_Cnt" overlaps "Track_Id" at line 13 > awdorrin.ads:15:30: info: reverse bit order in machine scalar of length 16 > awdorrin.ads:15:30: info: little-endian range for component "Track_Id_Cnt" is 6 .. 11 > gnatmake: "awdorrin.ads" compilation error This says that the first code specifies overlapping fields, which is not what you want. > Your way: > awdorrin.ads:13:26: info: reverse bit order in machine scalar of length 32 > awdorrin.ads:13:26: info: little-endian range for component "Track_Id" is 20 .. 31 > awdorrin.ads:14:30: info: reverse bit order in machine scalar of length 32 > awdorrin.ads:14:30: info: little-endian range for component "Track_Id_Cnt" is 14 .. 19 This says the two fields occupy the 16 bits numbered 31 .. 19, and are consecutive. Why do you say this is buggy? -- -- Stephe