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.224.192.199 with SMTP id dr7mr12209123qab.4.1358848164424; Tue, 22 Jan 2013 01:49:24 -0800 (PST) X-Received: by 10.49.4.231 with SMTP id n7mr2016022qen.34.1358848163939; Tue, 22 Jan 2013 01:49:23 -0800 (PST) Path: k2ni1457qap.0!nntp.google.com!p13no4070050qai.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 22 Jan 2013 01:49:23 -0800 (PST) In-Reply-To: <8a7a9e6f-6f87-44a7-942b-2275a9ecf049@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=194.98.77.221; posting-account=P1FCTgoAAABeb3_D1WlQxyfHqm50UZ8r NNTP-Posting-Host: 194.98.77.221 References: <20bda3de-b033-4b4e-8298-2ac47701b814@googlegroups.com> <0169b2ea-30b4-45d1-a4d4-c5841e54b9ad@googlegroups.com> <31facfa1-dae9-47c0-b5af-262e31c1d4f9@googlegroups.com> <63e09fad-16f0-468d-9d38-7969aaf3abe9@googlegroups.com> <8a7a9e6f-6f87-44a7-942b-2275a9ecf049@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: GNAT 4.4.5 Record Bit_Order Endian issues From: quinot@adacore.com Injection-Date: Tue, 22 Jan 2013 09:49:24 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2013-01-22T01:49:23-08:00 List-Id: On Friday, January 18, 2013 1:24:02 PM UTC+1, awdorrin wrote: =20 > I had a realization in the shower this morning: That's often where great ideas are hatched! :-) > The byte and bit ranges used in the specification clause is not describin= g memory locations, it is describing the location in the CPU register. The = Bit_Order flag is being used to describe which end of the CPU register is b= it zero. Right, this is exactly correct. > Due to the (byte level) endian differences, it would seem that it is not = possible to describe the physical bit locations in memory, since it is the = offset in the register that is being described. Correct. If you have a record where some components cross a storage unit bo= undary, then no standard rep clause can make it so that the record has the = same representation in memory on both big endian and little endian platform= s. > In order to get the record memory contents ordered the way I want them to= be, I'm going to have to play some byte swap games and translate the recor= d memory contents into a 'big endian buffer'.=20 > > Presumably, if the record contents can be defined in terms of a 32-bit 'm= achine scalar' - then this endian conversion can be done by starting at 'My= TrkRec'Address' and doing byte swaps on 4-byte (32-bit) groupings. Yes, that's a correct approach. > In C I'd simply make a 'uint32_t' pointer to the record address, and loop= through till the end of the record doing 'htonl()' calls. But Ada doesn't = make things quite so 'easy' ;-) Well, easy enough :-) You can overlap an array of Interfaces.Unsigned_32 ov= er your record, and use GNAT.Byte_Swapping.Swap4 on each element. Also note that the latest development version of GNAT Pro introduces a new = implementation-defined attribute Scalar_Storage_Order which precisely aims = at relieving programmers from having to do such byte-swapping "by hand" and= provide a means to force a record to have the same representation whether = the target is big-endian or little-endian (http://www.adacore.com/developer= s/development-log/NF-71-L207-008-gnat/). An article about this feature will appear next week in our Ada Gems series = (http://www.adacore.com/adaanswers/gems/), and we also have submitted a tec= hnical paper on this matter to the upcoming Ada Europe 2013 conference. Thomas Quinot.