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-26 08:07:03 PST
Path: 
 archiver1.google.com!news2.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!colt.net!dispose.news.demon.net!news.demon.co.uk!demon!pogner.demon.co.uk!zap!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Hi byte and Lo Byte Question
Date: 25 Aug 2001 08:15:43 +0100
Organization: CodeFella
Message-ID: <x7velq0k3ts.fsf@smaug.pushface.org>
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>
NNTP-Posting-Host: localhost
X-NNTP-Posting-Host: pogner.demon.co.uk:158.152.70.98
X-Trace: news.demon.co.uk 998838397 nnrp-01:4508 NO-IDENT
 pogner.demon.co.uk:158.152.70.98
X-Complaints-To: abuse@demon.net
NNTP-Posting-Date: 25 Aug 2001 07:15:43 GMT
X-Newsreader: Gnus v5.7/Emacs 20.7
Xref: archiver1.google.com comp.lang.ada:12432
Date: 2001-08-25T07:15:43+00:00
List-Id: <comp.lang.ada>

"Warren W. Gay VE3WWG" <ve3wwg@home.com> 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.

  [...]

  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.