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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,3110709241972620
X-Google-Attributes: gid103376,public
From: mheaney@ni.net (Matthew Heaney)
Subject: Re: Packing Record Structures in Ada
Date: 1998/01/12
Message-ID: <mheaney-ya023680001201982350020001@news.ni.net>#1/1
X-Deja-AN: 315473430
Content-Transfer-Encoding: 8bit
References: <884639188.24707084@dejanews.com>
Content-Type: text/plain; charset=ISO-8859-1
Organization: Estormza Software
Mime-Version: 1.0
Newsgroups: comp.lang.ada
Date: 1998-01-12T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <884639188.24707084@dejanews.com>, Randall_Rathbun@rc.trw.com wrote:

>Has anyone struggled and fixed the following problem with ordering inside
>the Ada83 record structure? We are working with two compilers, call them
>A & B, and they pack the record structure inversely. A typical example:
>type sample_message_type is
>   record
>      first_field  : unsigned_20_bits_type;
>      second_field : unsigned_22_bits_type;
>      third_field  : unsigned_22_bits_type;
>   end record
>sample_message : sample_message_type;

You haven't specified what the representation is.  You MUST specify the
representation of all data that leaves an Ada application, and transmitted
to an external device.

The solution is simple: include a representation clause for your type, as in

for Sample_Message_Type use
   record
      First_Field at 0 range 0 .. 19;
      Second_Field at 0 range 20 .. 41;
      Third_Field    at 0 range 42 .. 63;
   end record;

for Sample_Message_type'Size use 64;

Since you didn't specify the representation of the type, the compiler is
free to place the record components where ever it feels like.

Watch out for endian issues.  Are computers the same endianess?  You may
have to do byte-swapping too.

Make sure you get the positions correct.  Ada is consistent in the sense
that a bigger value means a bigger address, but this is contrary to what
you'd expect on a big-endian machine.  For example,

type RT is
   record
      B : Boolean;
   end record;

for RT use
   record
      B at 0 range 0 .. 0;
   end record;

for RT'Size use 8;

On a little endian machine, B is where you expect it: at the least
significant bit, at the position corresponding to the value 2 ** 0.

However, on a big endian machine, the same declaration puts B at the most
significant bit, at the position corresponding to the value 2 ** 7.

This "feature" of Ada can be mitigated by using the Bit_Order attribute
(available only in Ada 95 though), but I don't think any compiler actually
supports it.  I hope I'm wrong.  Even with it, you still have an ...um...
"issue" indexing packed bit arrays.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271