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.24.130 with SMTP id u2mr427278wif.6.1358501837050;
        Fri, 18 Jan 2013 01:37:17 -0800 (PST)
Path: 
 o9ni4815wio.1!nntp.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!nx02.iad01.newshosting.com!newshosting.com!69.16.185.16.MISMATCH!npeer02.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 <stephen_leake@stephe-leake.org>
Newsgroups: comp.lang.ada
Subject: Re: GNAT 4.4.5 Record Bit_Order Endian issues
References: <20bda3de-b033-4b4e-8298-2ac47701b814@googlegroups.com>
 	<0169b2ea-30b4-45d1-a4d4-c5841e54b9ad@googlegroups.com>
 	<ly38xzv86c.fsf@pushface.org>
 	<31facfa1-dae9-47c0-b5af-262e31c1d4f9@googlegroups.com>
 	<63e09fad-16f0-468d-9d38-7969aaf3abe9@googlegroups.com>
Date: Fri, 18 Jan 2013 04:37:16 -0500
Message-ID: <85ehhi4ysz.fsf@stephe-leake.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (windows-nt)
Cancel-Lock: sha1:d8iz8/x8dZl+vQcTLpkMI43iGyM=
MIME-Version: 1.0
X-Complaints-To: abuse@flashnewsgroups.com
Organization: FlashNewsgroups.com
X-Trace: caed150f917cce029e66115487
X-Received-Bytes: 2187
Content-Type: text/plain
Date: 2013-01-18T04:37:16-05:00
List-Id: <comp.lang.ada>

awdorrin <awdorrin@gmail.com> writes:

> Given the previous definition, the mapping to memory is not what I am
> expecting. (Which is why I thought I needed the Bit_Order =
> System.High_Order_First)
>
> Given: TRACK_ID_X at 0 range 0 .. 11;
>
> MyTrkRec.Track_Id_X = 2748; -- 0xabc
>
> Using GDB to debug and print the byte values:
> On a little endian system, I get: 0xcb 0x0a
> On a big endian system, using the original code, I get: 0xab 0xc0
>
> Now, I expect the numbers to be reordered, due to the endian
> differences.
>
> On Intel, using Bit_Order = System.High_Order_First,
> I would have expected to see: 0xcb 0xa0

There are two different kinds of "endianness"; bit endianness, and
byte endianness. 

"bit endianness" is about how to interpret the bit numbers in record rep
specs.

"byte endianness" is about how bytes are ordered in memory

Cohen's paper, and the Bit_Order attribute, only address bit endianness,
not byte endianness.

So if you are writing a multi-byte field to a machine register, or to a
network stream, you need to do byte swapping; Bit_Order does not affect
that. 

> This is why I thought the Bit_Order flag was used to fix.

That is a common misconception. And the ARM is not clear here.

-- 
-- Stephe