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=0.8 required=5.0 tests=BAYES_00,
	GUARANTEED_100_PERCENT autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,38ceb882eed41e1e
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-10-11 01:56:11 PST
Path: 
 archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!news.tele.dk!small.news.tele.dk!195.238.2.15!skynet.be!skynet.be!dispose.news.demon.net!news.demon.co.uk!demon!pipehawk.demon.co.uk!not-for-mail
From: john.mccabe@emrad.com.nospam (John McCabe)
Newsgroups: comp.lang.ada
Subject: Re: Size and pack
Date: Thu, 11 Oct 2001 08:55:45 GMT
Organization: Emrad Ltd
Message-ID: <3bc55c38.3322217@news.demon.co.uk>
References: <9ff447f2.0110100005.2503bb00@posting.google.com>
 <3BC40DF2.9447F025@icn.siemens.de> <3bc41989.4285341@news.demon.co.uk>
 <9ff447f2.0110102236.712cb9ea@posting.google.com>
NNTP-Posting-Host: pipehawk.demon.co.uk
X-NNTP-Posting-Host: pipehawk.demon.co.uk:158.152.226.81
X-Trace: news.demon.co.uk 1002790555 nnrp-12:22651 NO-IDENT
 pipehawk.demon.co.uk:158.152.226.81
X-Complaints-To: abuse@demon.net
X-Newsreader: Forte Free Agent 1.21/32.243
Xref: archiver1.google.com comp.lang.ada:14226
Date: 2001-10-11T08:55:45+00:00
List-Id: <comp.lang.ada>

On 10 Oct 2001 23:36:46 -0700, byhoe@greenlime.com (Adrian Hoe) wrote:

>I investigated the memory location of every components in record. The
>memory location (byte sequences which have been allocated) is of no
>difference if I applied:
>
>1. pragma pack
>2. representation clauses
>3. both pragma pack and representation clauses.
>
>What kind of assurance the compiler can offer if we use the above
>approach?

As far as I remember, if a representation clause is supported by the
compiler (check it's Annexe M documentation in case it does something
odd), it should be guaranteed.

>What is the portability issue (if any) from a 32-bit to
>64-bit processor?

Depends on the compiler. The example earlier...

>       for rx_header_data_packed use record       
>          start_byte   at  0 range  0 ..  7;
>          splitter     at  1 range  0 ..  7;
>          command_byte at  2 range  0 ..  7;
>          pad_byte_1   at  3 range  0 ..  7;
>          log_num      at  4 range  0 .. 31;  -- Changed
>          pad_byte_2   at  8 range  0 ..  7;  -- Changed
>          end_byte     at  9 range  0 ..  7;
>          lrc          at 10 range  0 ..  7;
>       end record;

Could also be written as:
for rx_header_data_packed use record       
   start_byte   at 0 range   0 ..  7;
   splitter     at 0 range   8 .. 15;
   command_byte at 0 range  16 .. 23;
   pad_byte_1   at 0 range  24 .. 31;
   log_num      at 0 range  32 .. 63;
   pad_byte_2   at 0 range  64 .. 71;
   end_byte     at 0 range  72 .. 79;
   lrc          at 0 range  80 .. 87;
end record;

which would remove the possibility of confusion because of different
storage unit sizes.

Ultimately, despite Ada's famed portability, nothing is 100%
guaranteed (especially if you use a different compiler) and you'd be
advised to make sure it still looks like it did before on a different
machine.

>Also, if the insertion of unused bytes by the compiler is to optimize,
>what could it be? Speed or space?

Generally speed because accesses to 1x whole word is quicker than
access to 2x parts of words. However space can come into it, because
to access 2x parts of words takes more code than accessing 1x whole
word. Whether space is improved depends on how many object of the type
you are using and how many different places you are using it.