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: nobody@REPLAY.COM (Anonymous)
Subject: Re: Packing Record Structures in Ada
Date: 1998/01/19
Message-ID: <199801191525.QAA01845@basement.replay.com>#1/1
X-Deja-AN: 317361182
Content-Transfer-Encoding: 7bit
References: <884639188.24707084@dejanews.com> 
Content-Type: text/plain; charset=us-ascii
Organization: Replay Associates, L.L.P.
Mail-To-News-Contact: postmaster@nym.alias.net
X-001: Replay may or may not approve of the content of this posting
X-002: Report misuse of this automated service to <abuse@replay.com>
X-URL: http://www.replay.com/remailer/
Newsgroups: comp.lang.ada
Date: 1998-01-19T00:00:00+00:00
List-Id: <comp.lang.ada>


On Mon, 12 Jan 1998 22:52:55 -0600, 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;
> 
> When compiler A sends a message out across a bus, it will send
>   |1.........20|21......32|   1st quad-word
>    first field   second
>   |1...10|11............32|   2nd quad-word
>     2nd      third field
> 
> However when the message is received, using compiler B it gets
>   |1.....12|13..........32|   1st quad-word
>     2nd        1st field
>   |1...........22|23....32|   2nd quad-word
>     3rd field      2nd
> (this is due to the way data is sent across the bus, 32 bits at a
> time)
> When the 2nd compiler B tries to understand what compiler A sent,
> it will force its interpretation, but since the relative order has
> been horizontally flipped, garbage results. One compiler stacks 8 bit
> bytes left-to-right inside the quadword, the other in the opposite
> order.
> 
> If you've encountered this problem in Ada83, and developed work-arounds,
> I'd like to hear from you Currently we're using a rotate function that
> uses the "with System" module to remedy this ugly mess. Thanks!
> please email: Randall_Rathbun@rc.trw.com
> 
> -------------------==== Posted via Deja News ====-----------------------
>       http://www.dejanews.com/     Search, Read, Post to Usenet
> 
> 

What do you get if you use

type Byte is range 0 .. 255; -- This is Ada 83
for Byte'Size use 8;

type Byte_9 is array (1 .. 9) of Byte;
for Byte_9'Size use 9 * 8;
pragma Pack (Byte_9);

M : Sample_Message_Type;
C : Byte_9;

C (1) := M.First_Field rem 256; -- LSB
C (2) := (M.First_Field / 256) rem 256; -- Middle byte
C (3) := M.First_Field / (256 ** 2); -- MSB
C (4) := M.Second_Field rem 256; -- LSB

.. 

-- C (1 .. 3) contains First_Field, little endian byte order
-- C (4 .. 6)    "     Second_ "  ,          "
-- C (7 .. 9)    "     Third_  "  ,          "

Send C from A to B. On B, reverse:

M.First_Field := (256 ** 2) * C (3) + 256 * C (2) + C (1);

..

This generally works. With Ada, you can use modular types, and shifts
and logical operations instead of arithmetic operations. It should also
work to send from B to A.

Jeff Carter  PGP:1024/440FBE21
My real e-mail address: ( carter @ innocon . com )
"English bed-wetting types."
Monty Python & the Holy Grail

Posted with Spam Hater - see
http://www.compulink.co.uk/~net-services/spam/