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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4e9860765413318c X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-27 09:33:36 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!east1.newsfeed.sprint-canada.net!news.storm.ca!nnrp1.tor.metronet.ca!not-for-mail Message-ID: <3B8A765E.3080702@home.com> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Hi byte and Lo Byte Question References: <9m0gn6$b6j$1@zeus.orl.lmco.com> <3B843C0C.9A3282B@raytheon.com> <9m34r7$6ka$1@nh.pace.co.uk> <3B860BD6.7A1A8EA3@eraseme.systems.saab.se> <3B867ECA.80502@home.com> <9m61gv$b8s$1@nh.pace.co.uk> <3B8692DE.9000206@home.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 27 Aug 2001 16:33:36 GMT NNTP-Posting-Host: 198.96.47.195 NNTP-Posting-Date: Mon, 27 Aug 2001 10:33:36 MDT Organization: MetroNet Communications Group Inc. Xref: archiver1.google.com comp.lang.ada:12467 Date: 2001-08-27T16:33:36+00:00 List-Id: Simon Wright wrote: > "Warren W. Gay VE3WWG" writes: >>Marin David Condic wrote: >>>What's wrong with ARM 13.5.3 Bit Ordering and using "for X'Bit_Order use >>>High_Order_First ;" and similar (Low_Order_First )? I'm pretty sure that >>>should work and do what you want - never needed to mess with it myself - >>>yet. (Day ain't over, yet!) >>> >>I had forgotten about that (and not used it yet). But I was under >>the impression that it only affects the numbering of the bits -- not >>the actual implementation of the "word". I'll have to review it again. > > From the 3.13p GNAT RM: > > In the case where the non-standard value is specified, the effect is > to renumber bits within each bit, but the ordering of bytes is not > affected. So this confirms my suspicion. It does not change the external representation in any way, just gives you the facility to renumber the bits, presumably for convenience or to specifically state what bit ordering is assumed in the source code. > Components occuping an integral number of bytes These are components > that exactly fit in two or more bytes. Such component declarations > are allowed, but have no effect, since it is important to realize that > the Bit_Order specification does not affect the ordering of bytes. In > particular, the following attempt at getting an endian-indepedent > integer does not work: > > type R2 is record > A : Integer; > end record; > > for R2'Bit_Order use High_Order_First; > > for R1 use record > A at 0 range 0 .. 31; > end record; > > This declaration will result in a little-endian integer on a > little-endian machine, and a big-endian integer on a big-endian > machine. if byte flipping is required for interoperability between > big- and little-endian machines, this must be explicitly > programmed. This capability is not provided by Bit_Order. > > This doesn't appear to have changed at 3.14a1. Given that this is a "language mandated thing" (ARM 13.5.3), I would not expect it to change. -- Warren W. Gay VE3WWG http://members.home.net/ve3wwg