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,bb163c965c676b88
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.66.72.73 with SMTP id b9mr1291051pav.9.1348283279738;
        Fri, 21 Sep 2012 20:07:59 -0700 (PDT)
Path: 
 t10ni4273025pbh.0!nntp.google.com!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: Endianness and Record Specification
References: <a0647230-14c8-4ece-8ed6-d23bdf130776@googlegroups.com>
 	<6c9fa5ab-588f-4a4b-929a-23f850913ceb@googlegroups.com>
Date: Fri, 21 Sep 2012 23:07:56 -0400
Message-ID: <85d31edab7.fsf@stephe-leake.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (windows-nt)
Cancel-Lock: sha1:0NmwurozJ+kTbm8rcrLLp3lqssk=
MIME-Version: 1.0
X-Complaints-To: abuse@flashnewsgroups.com
Organization: FlashNewsgroups.com
X-Trace: 938c8505d2b8fe029e66102042
X-Received-Bytes: 3781
Content-Type: text/plain
Date: 2012-09-21T23:07:56-04:00
List-Id: <comp.lang.ada>

awdorrin <awdorrin@gmail.com> writes:

> I think I found the cause of some of my confusion.
> The Gnat compiler treats the record specifications differently
> depending on if the code is compiled as Ada95 or Ada2005...
>
> Under '05 it produces the following output:
> mytest.adb:26:22: info: reverse bit order in machine scalar of length 16
> mytest.adb:26:22: info: little-endian range for component "Res" is 15 .. 15
>
> And the big endian specification is reordered. Under Ada95 this does not happen.
>
> Hmm...

Yes. Ada 2005 finally got bit-endianness right; all you have to do is
specify what the bit numbers in your record spec mean, by giving
'Bit_Order. Then the compiler does the Right Thing.

See http://www.ada-auth.org/ai-files/grab_bag/bitorder.pdf

So these two record specs represent the same bit layout:

   type Other_Date_And_Time_Type is record
      Years_Since_1980 : Unsigned_7;
      Month            : Unsigned_4;
      Day_Of_Month     : Unsigned_5;
      Hour             : Unsigned_5;
      Minute           : Unsigned_6;
      Seconds          : Unsigned_5;
   end record;

   for Other_Date_And_Time_Type'Bit_Order use System.High_Order_First;
   for Other_Date_And_Time_Type use record
      Years_Since_1980 at 0 range 0 .. 6;
      Month            at 0 range 7 .. 10;
      Day_Of_Month     at 0 range 11 .. 15;
      Hour             at 2 range 0 .. 4;
      Minute           at 2 range 5 .. 10;
      Seconds          at 2 range 11 .. 15;
   end record;

   type Date_And_Time_Type is record
      Years_Since_1980 : Unsigned_7;
      Month            : Unsigned_4;
      Day_Of_Month     : Unsigned_5;
      Hour             : Unsigned_5;
      Minute           : Unsigned_6;
      Seconds          : Unsigned_5;
   end record;
   for Date_And_Time_Type'Bit_Order use System.Low_Order_First;
   for Date_And_Time_Type use record
      Years_Since_1980 at 0 range 9 .. 15;
      Month            at 0 range 5 .. 8;
      Day_Of_Month     at 0 range 0 .. 4;
      Hour             at 2 range 11 .. 15;
      Minute           at 2 range 5 .. 10;
      Seconds          at 2 range 0 .. 4;
   end record;

GNAT is a little paranoid about this and outputs all kinds of "helpful"
informational messages. I think there are now ways to turn them all off,
once you are comfortable that the compiler is doing the right thing.


In Ada 95, the best you could expect was that the compiler would
complain that the endianness was "wrong". I used to have a work-around
for Ada 95, that looked something like this:

   for Good_Date_And_Time_Type use record
      Years_Since_1980 at 0 range
        Low_Bit_First  * (LSBit_16 + Bit_Order * 9) + High_Bit_First * (LSBit_32 + Bit_Order * 15) ..
        High_Bit_First * (LSBit_16 + Bit_Order * 9) + Low_Bit_First  * (LSBit_32 + Bit_Order * 15);
   end record;

But I have deleted the spec that defines LSBit_16 and LSBit_32; the
depend on the endianness of the target.

--
-- Stephe