Size and pack

Size and pack

[Adrian Hoe]

Hello,

I have the following declaration:

   type Rx_Header_Data is
      record
         Start_Byte   : Character := Latin_1.STX;
         Splitter     : Character;
         Command_Byte : Character;
         Pad_Byte_1   : Character;
         Pad_Byte_2   : Character;
         Log_Num      : Interfaces.C.Long;
         End_Byte     : Character := Latin_1.ETX;
         LRC          : Character;
      end record;

It supposed to be 11 bytes long but Rx_Header_Data'Size reports 14
bytes. 'Size will report 11 bytes when I add the following line:

pragma pack (Rx_Header_Data);

I have found that Log_Num : Interfaces.C.Long takes up 7 bytes without
pragma pack.

Why this happens? Can I use representation clause instead of pragma
pack? If both methods work, which is the best approach and why?

I use GNAT 3.13p on Linux.

Thank you.

Re: Size and pack

[Alfred Hilscher]

I'm not sure, but I think it is because Log_Num would start on an odd
adress otherwise, and so there are three bytes left  to align it to a
word boundary. Yes, shou should be able to do it with rep-spec.

Adrian Hoe wrote:
> 
> Hello,
> 
> I have the following declaration:
> 
>    type Rx_Header_Data is
>       record
>          Start_Byte   : Character := Latin_1.STX;
>          Splitter     : Character;
>          Command_Byte : Character;
>          Pad_Byte_1   : Character;
>          Pad_Byte_2   : Character;
>          Log_Num      : Interfaces.C.Long;
>          End_Byte     : Character := Latin_1.ETX;
>          LRC          : Character;
>       end record;
> 
> It supposed to be 11 bytes long but Rx_Header_Data'Size reports 14
> bytes. 'Size will report 11 bytes when I add the following line:
> 
> pragma pack (Rx_Header_Data);
> 
> I have found that Log_Num : Interfaces.C.Long takes up 7 bytes without
> pragma pack.
> 
> Why this happens? Can I use representation clause instead of pragma
> pack? If both methods work, which is the best approach and why?
> 
> I use GNAT 3.13p on Linux.
> 
> Thank you.

Re: Size and pack

[Pi]

Adrian Hoe wrote :

> Hello,
> 
> I have the following declaration:
> 
>    type Rx_Header_Data is
>       record
>          Start_Byte   : Character := Latin_1.STX;
1st byte
>          Splitter     : Character;
2nd byte
>          Command_Byte : Character;
3rd byte
>          Pad_Byte_1   : Character;
4th byte
>          Pad_Byte_2   : Character;
5th byte
3 bytes space to align with a memory word (32 bit)
>          Log_Num      : Interfaces.C.Long;
8th - 12th byte
>          End_Byte     : Character := Latin_1.ETX;
13th byte
>          LRC          : Character;
14th byte
>       end record;
> 
> It supposed to be 11 bytes long but Rx_Header_Data'Size reports 14
> bytes. 'Size will report 11 bytes when I add the following line:
> 
> pragma pack (Rx_Header_Data);
> 
> I have found that Log_Num : Interfaces.C.Long takes up 7 bytes without
> pragma pack.
> 
> Why this happens? Can I use representation clause instead of pragma
> pack? If both methods work, which is the best approach and why?
> 
> I use GNAT 3.13p on Linux.
> 
> Thank you.

It's much faster to access variables that are on full word-frontiers,
so GNAT adds a 3 bytes "hole" into your record.

Try this definition instead :

   type Rx_Header_Data is
      record
         Log_Num      : Interfaces.C.Long; <-------1st position
         Start_Byte   : Character := Latin_1.STX;
         Splitter     : Character;
         Command_Byte : Character;
         Pad_Byte_1   : Character;
         Pad_Byte_2   : Character;
         End_Byte     : Character := Latin_1.ETX;
         LRC          : Character;
      end record;

Yes I know it's silly to simply shuffle the definitions,
but it should work.

Also try to compile with full optimization (-O3) and GNAT may
find the shuffle himself (not sure about this)

If, for some reasons, you cant shuffle the definitions,
you have to use Pack.
If you can, shuffle, as Pack makes your memory access slighly slower.

-- 
3,14159265359

Re: Size and pack

[Lutz Donnerhacke]

* Adrian Hoe wrote:
>I have the following declaration:
>   type Rx_Header_Data is
>      record
>         Start_Byte   : Character := Latin_1.STX;
>         Splitter     : Character;
>         Command_Byte : Character;
>         Pad_Byte_1   : Character;
>         Pad_Byte_2   : Character;

Five Bytes so far.

>         Log_Num      : Interfaces.C.Long;
>         End_Byte     : Character := Latin_1.ETX;
>         LRC          : Character;
>      end record;
>
>It supposed to be 11 bytes long but Rx_Header_Data'Size reports 14
>bytes. 'Size will report 11 bytes when I add the following line:
>
>pragma pack (Rx_Header_Data);
>
>I have found that Log_Num : Interfaces.C.Long takes up 7 bytes without
>pragma pack.

As expected.

>Why this happens?

Log_Num is aligned to use a single 64bit RAM access instead of bursting two
32bit accesses. Pragma Pack favors size over speed.

>Can I use representation clause instead of pragma pack?

Yes.

>If both methods work, which is the best approach and why?

Depends on your needs:
  - If you only need the small size, let the compiler choose the
    representation. (-gnatR shows the compilers decision)
      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;
  - If you need a special layout (i.e. for interfacing),
    use record representation clauses.

Re: Size and pack

[John McCabe]

On Wed, 10 Oct 2001 10:59:30 +0200, Alfred Hilscher
<Alfred.Hilscher@icn.siemens.de> wrote:

Sorry I missed the original post but...

>> Why this happens? Can I use representation clause instead of pragma
>> pack? If both methods work, which is the best approach and why?

Your best bet would be to use as many representation attributes as are
necessary. In general I would use both a representation clause and
pragma pack on an item such as this, and possibly an alignment clause,
to guarantee as much as possible that the record layout in memory is
the way that you want it.

Re: Size and pack

[Adrian Hoe]

lutz@iks-jena.de (Lutz Donnerhacke) wrote in message news:<slrn9s853b.k4.lutz@taranis.iks-jena.de>...
> * Adrian Hoe wrote:
> >I have the following declaration:
> >   type Rx_Header_Data is
> >      record
> >         Start_Byte   : Character := Latin_1.STX;
> >         Splitter     : Character;
> >         Command_Byte : Character;
> >         Pad_Byte_1   : Character;
> >         Pad_Byte_2   : Character;
> 
> Five Bytes so far.
> 
> >         Log_Num      : Interfaces.C.Long;
> >         End_Byte     : Character := Latin_1.ETX;
> >         LRC          : Character;
> >      end record;
> >
> >It supposed to be 11 bytes long but Rx_Header_Data'Size reports 14
> >bytes. 'Size will report 11 bytes when I add the following line:
> >
> >pragma pack (Rx_Header_Data);
> >
> >I have found that Log_Num : Interfaces.C.Long takes up 7 bytes without
> >pragma pack.
> 
> As expected.
> 
> >Why this happens?
> 
> Log_Num is aligned to use a single 64bit RAM access instead of bursting two
> 32bit accesses. Pragma Pack favors size over speed.
> 
> >Can I use representation clause instead of pragma pack?
> 
> Yes.
> 
> >If both methods work, which is the best approach and why?
> 
> Depends on your needs:
>   - If you only need the small size, let the compiler choose the
>     representation. (-gnatR shows the compilers decision)
>       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;
>   - If you need a special layout (i.e. for interfacing),
>     use record representation clauses.



The record structure will be used to interface with COTS product which
sends out data in specific byte orders. The shuffle is not viable in
this case.

This will be intended on 32-bit Intel. What will be the effect if I
use representation clauses on 64-bit processor?

Adrian

Re: Size and pack

[Adrian Hoe]

john.mccabe@emrad.com.nospam (John McCabe) wrote in message news:<3bc41989.4285341@news.demon.co.uk>...
> On Wed, 10 Oct 2001 10:59:30 +0200, Alfred Hilscher
> <Alfred.Hilscher@icn.siemens.de> wrote:
> 
> Sorry I missed the original post but...
> 
> >> Why this happens? Can I use representation clause instead of pragma
> >> pack? If both methods work, which is the best approach and why?
> 
> Your best bet would be to use as many representation attributes as are
> necessary. In general I would use both a representation clause and
> pragma pack on an item such as this, and possibly an alignment clause,
> to guarantee as much as possible that the record layout in memory is
> the way that you want it.


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? What is the portability issue (if any) from a 32-bit to
64-bit processor?

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

Adrian

Re: Size and pack

[John McCabe]

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.

Re: Size and pack

[John McCabe]

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

>The record structure will be used to interface with COTS product which
>sends out data in specific byte orders. The shuffle is not viable in
>this case.

I thought that may be the case, otherwise why be concerned with the
structure :-)

>This will be intended on 32-bit Intel. What will be the effect if I
>use representation clauses on 64-bit processor?

On a 64-bit Intel processor? It is likely that the layout will be the
same. You may need to be concerned about endianness- although there is
a 'Bit_Order attribute, in my experience a compiler is unlikely to
allow you to specify a bit order that is contrary to its native
ordering.

Re: Size and pack

[Lutz Donnerhacke]

* Adrian Hoe wrote:
>lutz@iks-jena.de (Lutz Donnerhacke) wrote in message news:<slrn9s853b.k4.lutz@taranis.iks-jena.de>...
>>   - If you need a special layout (i.e. for interfacing),
>>     use record representation clauses.
>
>The record structure will be used to interface with COTS product which
>sends out data in specific byte orders. The shuffle is not viable in
>this case.

So use record representation clauses.

>This will be intended on 32-bit Intel. What will be the effect if I
>use representation clauses on 64-bit processor?

With record representation clauses (including Bit_Order definitions) you can
expect portable access.

Re: Size and pack

[Vincent Smeets]

Adrian Hoe wrote:
> 
> Hello,
> 
> I have the following declaration:
> 
>    type Rx_Header_Data is
>       record
>          Start_Byte   : Character := Latin_1.STX;
>          Splitter     : Character;
>          Command_Byte : Character;
>          Pad_Byte_1   : Character;
>          Pad_Byte_2   : Character;
>          Log_Num      : Interfaces.C.Long;
>          End_Byte     : Character := Latin_1.ETX;
>          LRC          : Character;
>       end record;
> 
> It supposed to be 11 bytes long but Rx_Header_Data'Size reports 14
> bytes. 'Size will report 11 bytes when I add the following line:
> 
> pragma pack (Rx_Header_Data);
> 
> I have found that Log_Num : Interfaces.C.Long takes up 7 bytes without
> pragma pack.

Just an other view and a question to CLA,

If you read and write this record thrue a stream, will you then get the
correct byte layout (with Log_Num at an odd byte)?

-- 

Vincent Smeets
SchlumbergerSema -
Competence Center Informatik GmbH 
Lohberg 10 - 49716 Meppen - Germany
 tel: +49 5931-805-461
 fax: +49 5931-805-175
mail: VSmeets@slb.com
 web: www.cci.de

Re: Size and pack

[Lutz Donnerhacke]

* Vincent Smeets wrote:
>Adrian Hoe wrote:
>>    type Rx_Header_Data is
>>       record
>>          Start_Byte   : Character := Latin_1.STX;
>>          Splitter     : Character;
>>          Command_Byte : Character;
>>          Pad_Byte_1   : Character;
>>          Pad_Byte_2   : Character;
>>          Log_Num      : Interfaces.C.Long;
>>          End_Byte     : Character := Latin_1.ETX;
>>          LRC          : Character;
>>       end record;
>
>Just an other view and a question to CLA,
>
>If you read and write this record thrue a stream, will you then get the
>correct byte layout (with Log_Num at an odd byte)?

I do not see a reason for expecting it. The Implementation may choose to
start with a type marker and than dumps the current memory area.

Re: Size and pack

[David C. Hoos, Sr.]

----- Original Message ----- 
From: "Lutz Donnerhacke" <lutz@iks-jena.de>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: October 11, 2001 5:19 AM
Subject: Re: Size and pack


> * Vincent Smeets wrote:
> >Adrian Hoe wrote:
> >>    type Rx_Header_Data is
> >>       record
> >>          Start_Byte   : Character := Latin_1.STX;
> >>          Splitter     : Character;
> >>          Command_Byte : Character;
> >>          Pad_Byte_1   : Character;
> >>          Pad_Byte_2   : Character;
> >>          Log_Num      : Interfaces.C.Long;
> >>          End_Byte     : Character := Latin_1.ETX;
> >>          LRC          : Character;
> >>       end record;
> >
> >Just an other view and a question to CLA,
> >
> >If you read and write this record thrue a stream, will you then get the
> >correct byte layout (with Log_Num at an odd byte)?
> 
> I do not see a reason for expecting it. The Implementation may choose to
> start with a type marker and than dumps the current memory area.
>
The above answer is completely wrong.

The language standard is very clear about the behavior of stream
attributes.

Whether this type is written with 'Outpuit or 'Write, there will
be exactly eleven stream elements written to the stream.  Since this is
not a tagged type, there is no "type marker" to write.  Furthermore,
the behavior of 'Output and 'Write for this type is unaffected by
how the compiler chooses to lay out the record in memory -- whether
11 bytes or 14 bytes, or some other size, or even if the compiler should
choose a different order in which to lay out the components.  To say
"then dumps the current memory area" is misleading at best.

If this _were_ a tagged type, then the behavior of 'Write would be
exactly as described above, but 'Output would precede the data with
the External_Tag of the type.  Since an External_Tag is a string, the
stream representaion of an External_Tag is first a Standard.Integer
containing the length of the string, followed by the characters of the
string.

Furthermore, this behavior is unaffected by any representation
clause or Pragma Pack.

LRM 13.13.2 describes this behavior in detail.
_______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 

Re: Size and pack

[Lutz Donnerhacke]

* David C. Hoos, Sr. wrote:
>From: "Lutz Donnerhacke" <lutz@iks-jena.de>
>> I do not see a reason for expecting it. The Implementation may choose to
>> start with a type marker and than dumps the current memory area.
>
>The above answer is completely wrong.

Thanx. My fault. I was irritated by endianess problems.

Re: Size and pack

[Mark Johnson]

John McCabe wrote:

> On 10 Oct 2001 23:24:27 -0700, byhoe@greenlime.com (Adrian Hoe) wrote:
> [snip]

> You may need to be concerned about endianness- although there is
> a 'Bit_Order attribute, in my experience a compiler is unlikely to
> allow you to specify a bit order that is contrary to its native
> ordering.

Since Bit_Order is described in Chapter 13, all compilers should support
it. However, the way GNAT (and perhaps other compilers) implement this is
not the way I expected it. I expected on an Intel PC (little endian) when
you say...
  for T'Bit_Order use System.High_Order_First;
on a data type that has 'Size=32, that bit zero is the most significant bit
(as it would be on an big endian sgi). That is NOT true. Bit zero is the
MSB of byte zero (the least significant byte) of a four byte value.

Basically, the storage place attributes ('Position, 'First_Bit, 'Last_Bit)
are generated after normalizing the values so that 'First_Bit is less than
Storage_Unit. So something like...
 for C at 0 range 24..24;
with Storage_Size =8, you compute 'Position=3, 'First_Bit=0, 'Last_Bit=0.
This is the most significant bit in a 32 bit value if you applied
High_Order_First to the bit order.

[sigh]

It is a pain to define structures that are portable between both big and
little endian machines. Almost as big a pain as the related byte swapping
that is often needed. If someone wants a more detailed explanation of what
we found w/ this, I suggest starting a new thread.
  --Mark

Re: Size and pack

[Ted Dennison]

In article <9ff447f2.0110100005.2503bb00@posting.google.com>, Adrian Hoe says...
..
>Why this happens? Can I use representation clause instead of pragma
>pack? If both methods work, which is the best approach and why?

Why doesn't really matter. If your types must be a certian size and/or your
record fields must be in a certian order for your program to work, then you
*must* use representation and size pragmas to force that. Not specifying sizes
and record field locations is in effect telling the compiler that you don't
really care how big it is or where it puts things. Even if it happens to work
out allright today, it might not upon your next compiler version upgrade or
software port.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: Size and pack

[Pat Rogers]

"John McCabe" <john.mccabe@emrad.com.nospam> wrote in message
news:3bc5c72d.30703258@news.demon.co.uk...
> On Thu, 11 Oct 2001 08:20:15 -0500, Mark Johnson
> <Mark_H_Johnson@Raytheon.com> wrote:
>
>
> >Since Bit_Order is described in Chapter 13, all compilers should support
> >it.
>
> There is a differenc between supporting it and doing anything useful
> with it, e.g. GNAT 3.12a2 or whatever it was that my last place had
> for Solaris was quite happy for you to say:
>
> for x'bit_order use a_order_first
>
> but blew up when you tried
>
> for x'bit_order use b_order_first
>
> (Can't remember which way round a and b were!)


That has changed since that (now quite old) version.

Re: Size and pack

[John McCabe]

On Thu, 11 Oct 2001 08:20:15 -0500, Mark Johnson
<Mark_H_Johnson@Raytheon.com> wrote:


>Since Bit_Order is described in Chapter 13, all compilers should support
>it.

There is a differenc between supporting it and doing anything useful
with it, e.g. GNAT 3.12a2 or whatever it was that my last place had
for Solaris was quite happy for you to say:

for x'bit_order use a_order_first

but blew up when you tried

for x'bit_order use b_order_first

(Can't remember which way round a and b were!)

Re: Size and pack

[John McCabe]

On Thu, 11 Oct 2001 16:00:37 GMT, "Pat Rogers" <progers@classwide.com>
wrote:

>> There is a differenc between supporting it and doing anything useful
>> with it, e.g. GNAT 3.12a2 or whatever it was that my last place had
>> for Solaris was quite happy for you to say:
>>
>> for x'bit_order use a_order_first
>>
>> but blew up when you tried
>>
>> for x'bit_order use b_order_first
>>
>> (Can't remember which way round a and b were!)
>
>
>That has changed since that (now quite old) version.

That may be so, but the point was that you can't guarantee that a
compiler will always behave as you think it should.

Re: Size and pack

[Smark]

"Adrian Hoe" <byhoe@greenlime.com> wrote in message
news:9ff447f2.0110100005.2503bb00@posting.google.com...
> Hello,
>
> I have the following declaration:
>
>    type Rx_Header_Data is
>       record
>          Start_Byte   : Character := Latin_1.STX;
>          Splitter     : Character;
>          Command_Byte : Character;
>          Pad_Byte_1   : Character;
>          Pad_Byte_2   : Character;
>          Log_Num      : Interfaces.C.Long;
>          End_Byte     : Character := Latin_1.ETX;
>          LRC          : Character;
>       end record;
>
> It supposed to be 11 bytes long but Rx_Header_Data'Size reports 14
> bytes. 'Size will report 11 bytes when I add the following line:
>
> pragma pack (Rx_Header_Data);
>
> I have found that Log_Num : Interfaces.C.Long takes up 7 bytes without
> pragma pack.
>
> Why this happens? Can I use representation clause instead of pragma
> pack? If both methods work, which is the best approach and why?
>
> I use GNAT 3.13p on Linux.
>
> Thank you.

As you indicated in another post, neither pragma pack nor a rep clause
gives you what you want.  This is because neither of these will violate
the alignment rules for a given type.  Unless you can use Streams_Io
to read and write (and you don't have to worry about what the data looks
like otherwise), you will have to do something ugly, like:

    type Rx_Header_Data is
       record
          Start_Byte   : Character := Latin_1.STX;
          Splitter     : Character;
          Command_Byte : Character;
          Pad_Byte_1   : Character;
          Pad_Byte_2   : Character;
          L0      : Character;
          L1      : Character;
          L2      : Character;
          L3      : Character;
          End_Byte     : Character := Latin_1.ETX;
          LRC          : Character;
       end record;

    subtype Str4 is String(1..4);
    function Convert is new Unchecked_Conversion
                (Source => Str4, Target => Interfaces.C.Long);

    Log_Num_Str : Str4 :=
         Rx_Header_Data.L0
         & Rx_Header_Data.L1
         & Rx_Header_Data.L2
         & Rx_Header_Data.L3;

   Log_Num : Interfaces.C.Long := Convert(Log_Num_Str);

Markku

Re: Size and pack

[tmoran]

>As you indicated in another post, neither pragma pack nor a rep clause
>gives you what you want.  This is because neither of these will violate
>the alignment rules for a given type.
  I seem to have missed the previous post, so I don't know what the
problem is.  The following code works just fine - isn't it what you want?
    type Rx_Header_Data is
       record
          Start_Byte   : Character := Latin_1.STX;
          Splitter     : Character;
          Command_Byte : Character;
          Pad_Byte_1   : Character;
          Pad_Byte_2   : Character;
          Log_Num      : Interfaces.C.Long;
          End_Byte     : Character := Latin_1.ETX;
          LRC          : Character;
       end record;
    for Rx_Header_Data 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;
          Pad_Byte_2   at 4 range 0 .. 7;
          Log_Num      at 5 range 0 .. 31;
          End_Byte     at 9 range 0 .. 7;
          LRC          at 10 range 0 .. 7;
       end record;
    for Rx_Header_Data'size use 8*11;

    subtype str is String(1 .. 11);
    function to_str is new ada.unchecked_conversion(source=>Rx_Header_Data,
                                                    target=>str);
    a : Rx_Header_Data;
    b : str;
begin
  b := to_str(a);
-----------
(Of course it's really ugly to use String where Storage_Element is clearly
what is meant.)

Re: Size and pack

[Smark]

<tmoran@acm.org> wrote in message
news:8b7C7.72629$gT6.36974049@news1.rdc1.sfba.home.com...
> >As you indicated in another post, neither pragma pack nor a rep clause
> >gives you what you want.  This is because neither of these will violate
> >the alignment rules for a given type.
>   I seem to have missed the previous post, so I don't know what the
> problem is.  The following code works just fine - isn't it what you want?
>     type Rx_Header_Data is
>        record
>           Start_Byte   : Character := Latin_1.STX;
>           Splitter     : Character;
>           Command_Byte : Character;
>           Pad_Byte_1   : Character;
>           Pad_Byte_2   : Character;
>           Log_Num      : Interfaces.C.Long;
>           End_Byte     : Character := Latin_1.ETX;
>           LRC          : Character;
>        end record;
>     for Rx_Header_Data 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;
>           Pad_Byte_2   at 4 range 0 .. 7;
>           Log_Num      at 5 range 0 .. 31;
>           End_Byte     at 9 range 0 .. 7;
>           LRC          at 10 range 0 .. 7;
>        end record;
>     for Rx_Header_Data'size use 8*11;

The problem was that this rep clause will not work, because Log_Num must
be aligned to a 4-byte boundary.  Some compilers will silently ignore your
rep clause, I believe GNAT will tell you it can't do it.

>
>     subtype str is String(1 .. 11);
>     function to_str is new
ada.unchecked_conversion(source=>Rx_Header_Data,
>                                                     target=>str);
>     a : Rx_Header_Data;
>     b : str;
> begin
>   b := to_str(a);
> -----------
> (Of course it's really ugly to use String where Storage_Element is clearly
> what is meant.)

Agreed.

Markku

Re: Size and pack

[Jeffrey Carter]

Smark wrote:
> 
> <tmoran@acm.org> wrote in message
> news:8b7C7.72629$gT6.36974049@news1.rdc1.sfba.home.com...
> > >As you indicated in another post, neither pragma pack nor a rep clause
> > >gives you what you want.  This is because neither of these will violate
> > >the alignment rules for a given type.
> >   I seem to have missed the previous post, so I don't know what the
> > problem is.  The following code works just fine - isn't it what you want?
> >     type Rx_Header_Data is
> >        record
> >           Start_Byte   : Character := Latin_1.STX;
> >           Splitter     : Character;
> >           Command_Byte : Character;
> >           Pad_Byte_1   : Character;
> >           Pad_Byte_2   : Character;
> >           Log_Num      : Interfaces.C.Long;
> >           End_Byte     : Character := Latin_1.ETX;
> >           LRC          : Character;
> >        end record;
> >     for Rx_Header_Data 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;
> >           Pad_Byte_2   at 4 range 0 .. 7;
> >           Log_Num      at 5 range 0 .. 31;
> >           End_Byte     at 9 range 0 .. 7;
> >           LRC          at 10 range 0 .. 7;
> >        end record;
> >     for Rx_Header_Data'size use 8*11;
> 
> The problem was that this rep clause will not work, because Log_Num must
> be aligned to a 4-byte boundary.  Some compilers will silently ignore your
> rep clause, I believe GNAT will tell you it can't do it.

You don't seem to be paying attention. He said, "[This] code works just
fine". That probably means he tested it. I have compiled and linked it
with GNAT 3.13p/Win98 without any problem.

On what compiler/target did your test reject this rep clause? 

-- 
Jeff Carter
"I wave my private parts at your aunties."
Monty Python & the Holy Grail

Re: Size and pack

[tmoran]

> >           Log_Num      at 5 range 0 .. 31;
> >           End_Byte     at 9 range 0 .. 7;
> >           LRC          at 10 range 0 .. 7;
> >        end record;
> >     for Rx_Header_Data'size use 8*11;
>
> The problem was that this rep clause will not work, because Log_Num must
> be aligned to a 4-byte boundary.  Some compilers will silently ignore your
> rep clause, I believe GNAT will tell you it can't do it.
  I tested it on Gnat 3.13p on Windows before posting, and Gnat was
perfectly happy with it.  And ARM 13.5.1(23) says that "If component
clauses are given for all components, the record representation clause
completely specifies the representation of the type and will be obeyed
exactly by the implementation."  That seems pretty unambiguous to me.

Re: Size and pack

[Robert Dewar]

Mark Johnson <Mark_H_Johnson@Raytheon.com> wrote in message news:<3BC59C8E.BADA210D@Raytheon.com>...

> Since Bit_Order is described in Chapter 13, all compilers 
> should support it.

That's faulty reasoning. Let's look at the RM, it says that
the recommended level of support is:

7   The recommended level of support for the nondefault bit    
    ordering is:

    8  If Word_Size = Storage_Unit, then the implementation 
       should support the nondefault bit ordering in 
       addition to the default bit ordering.


First of all, a compiler that does not implement the systems
programming annex which is optional, is free to
reject *any* or *all* representation clauses.   

Second a compiler that *does* implement the systems programming annex
must treat recommended level statements
in chapter 13 as requirements. 

Third, even if a compiler does implement the systems
programming annex, it need not recognize any representation
clauses other than those that correspond to these statements about
recommended level of support.

So what does this mean for Bit_Order

a) A compiler not implementing the systems programming annex may
reject all such clauses.

b) A compiler that implements the systems programming annex may reject
all such clauses for machines where the word
size is not equal to a storage unit = all byte addressed
machines = pretty much all machines around these days.

So in other words, on a byte addressed machine you cannot expect the
non-standard bit order to be implemented at all.

Why the apparently surprising restriction? Well let's look
at the definition of Bit_Order:

2   A bit ordering is a method of interpreting the meaning of the
storage place attributes.  High_Order_First (known in the vernacular
as ``big endian'') means that the first bit of a storage element (bit
0) is the mostsignificant bit (interpreting the sequence of bits that
represent a componentas an unsigned integer value).  Low_Order_First
(known in the vernacular as``little endian'') means the opposite: the
first bit is the least significant.

In other words, the attribute affects ONLY the numbering of
bits WITHIN a storage unit, it does NOT affect the numbering of
storage units. The thinking of the designers was that this is of very
limited use on a byte addressed
machine, so what's the point of requiring it to be implemented. On a
word machine it is more useful.

In GNAT, we decided to implement it anyway, even though this is not
required, but of course we have to implement
it the way the RM specifies, so it only affects the numbering of bits
within a storage unit. So for example,
if you have:

   type r is record
      a,b,c : integer;
      d : short_Integer;
   end record;

it is meaningless to apply the non-default bit order because bit
numbering within storage units is not an
issue in this case

GNAT will issue a warning in this case that the selection
of bit order does nothing. Why a warning? Well it is our
experience that lots of people (Marc included I think) expect the
specification of bit order to magically fix the
difference between big-endian and little-endian representations.

In fact not only does it not do this at all, but there is
no obvious (or even non-obvious) way to define a facility
in Ada that *would* take care of this very difficult data
incompatibility in an automatic manner. A few people have
suggested ideas, but none of the ideas have held up.

So yes, I understand that the implementation in GNAT does
not meet Marc's expectations but unfortunately it is the
expectations that are fundamentally wrong, the implementation is
right, and any other compiler that accepts the same declarations must
do the same thing (of
course it would not be at all surprising if some other
compiler rejected the clause on a byte addressed machine,
and any use of the GNAT facility here is likely to be 
non-portable since it is a non-required, though allowed,
extension).

Robert Dewar
Ada Core Technologies

 





 However, the way GNAT (and perhaps other compilers) implement this is
> not the way I expected it. I expected on an Intel PC (little endian) when
> you say...
>   for T'Bit_Order use System.High_Order_First;
> on a data type that has 'Size=32, that bit zero is the most significant bit
> (as it would be on an big endian sgi). That is NOT true. Bit zero is the
> MSB of byte zero (the least significant byte) of a four byte value.
> 
> Basically, the storage place attributes ('Position, 'First_Bit, 'Last_Bit)
> are generated after normalizing the values so that 'First_Bit is less than
> Storage_Unit. So something like...
>  for C at 0 range 24..24;
> with Storage_Size =8, you compute 'Position=3, 'First_Bit=0, 'Last_Bit=0.
> This is the most significant bit in a 32 bit value if you applied
> High_Order_First to the bit order.
> 
> [sigh]
> 
> It is a pain to define structures that are portable between both big and
> little endian machines. Almost as big a pain as the related byte swapping
> that is often needed. If someone wants a more detailed explanation of what
> we found w/ this, I suggest starting a new thread.
>   --Mark

Re: Size and pack

[Adrian Hoe]

tmoran@acm.org wrote in message news:<_umC7.74983$gT6.38373531@news1.rdc1.sfba.home.com>...
> > >           Log_Num      at 5 range 0 .. 31;
> > >           End_Byte     at 9 range 0 .. 7;
> > >           LRC          at 10 range 0 .. 7;
> > >        end record;
> > >     for Rx_Header_Data'size use 8*11;
> >
> > The problem was that this rep clause will not work, because Log_Num must
> > be aligned to a 4-byte boundary.  Some compilers will silently ignore your
> > rep clause, I believe GNAT will tell you it can't do it.
>   I tested it on Gnat 3.13p on Windows before posting, and Gnat was
> perfectly happy with it.  And ARM 13.5.1(23) says that "If component
> clauses are given for all components, the record representation clause
> completely specifies the representation of the type and will be obeyed
> exactly by the implementation."  That seems pretty unambiguous to me.

I tested the code on GNAT 3.13p-7 on Linux and it works!

Is having, "for Rx_Header_Data'size use 8*11;" better than pragma
pack? What is the rational? I suppose the former tells the compiler
exactly how many bytes/bits to be allocated for Rx_Header_Data.

Adrian Hoe

Re: Size and pack

[tmoran]

>Is having, "for Rx_Header_Data'size use 8*11;" better than pragma
>pack? What is the rational?
  What I want is an 11 byte record.  What a future maintainer might
need to know is that it's an 11 byte record.  Perhaps "pragma pack"
is a way to accomplish that, and perhaps it will be obvious to a
future maintainer that such a record, when packed, is 11 bytes long,
but it would take mental energy, and be susceptible to error, to be sure.
If I didn't care about the layout, but just wanted to minimize storage,
then using "pragma pack" would be easier.

Re: Size and pack

[Lutz Donnerhacke]

* tmoran@acm.org wrote:
>> >           Log_Num      at 5 range 0 .. 31;
>> >           End_Byte     at 9 range 0 .. 7;
>> >           LRC          at 10 range 0 .. 7;
>> >        end record;
>> >     for Rx_Header_Data'size use 8*11;
>>
>> The problem was that this rep clause will not work, because Log_Num must
>> be aligned to a 4-byte boundary.  Some compilers will silently ignore your
>> rep clause, I believe GNAT will tell you it can't do it.
>
>  I tested it on Gnat 3.13p on Windows before posting, and Gnat was
>perfectly happy with it.  And ARM 13.5.1(23) says that "If component
>clauses are given for all components, the record representation clause
>completely specifies the representation of the type and will be obeyed
>exactly by the implementation."  That seems pretty unambiguous to me.

Compile on Alpha and get BUS ERROR.

Re: Size and pack

[Larry Kilgallen]

In article <slrn9tq9mi.nt.lutz@taranis.iks-jena.de>, lutz@iks-jena.de (Lutz Donnerhacke) writes:
> * tmoran@acm.org wrote:
>>> >           Log_Num      at 5 range 0 .. 31;
>>> >           End_Byte     at 9 range 0 .. 7;
>>> >           LRC          at 10 range 0 .. 7;
>>> >        end record;
>>> >     for Rx_Header_Data'size use 8*11;
>>>
>>> The problem was that this rep clause will not work, because Log_Num must
>>> be aligned to a 4-byte boundary.  Some compilers will silently ignore your
>>> rep clause, I believe GNAT will tell you it can't do it.
>>
>>  I tested it on Gnat 3.13p on Windows before posting, and Gnat was
>>perfectly happy with it.  And ARM 13.5.1(23) says that "If component
>>clauses are given for all components, the record representation clause
>>completely specifies the representation of the type and will be obeyed
>>exactly by the implementation."  That seems pretty unambiguous to me.
> 
> Compile on Alpha and get BUS ERROR.

Presumably that is a runtime rather than compilation time error.

You didn't say what model of Alpha, but older chips require
certain instructions be aligned.  VMS deals with this through
alignment fault handlers that fix up such problems at a penalty
of about 100 instructions.  Perhaps you are on Unix or Linux
(you didn't say in the body text).  If so, look at your compiler
instructions for something regarding which Alpha chip you are
targeting.  Specify an older chip and the resulting code should
work on all.

Re: Size and pack

[Adrian Hoe]

tmoran@acm.org wrote in message news:<633D7.83856$gT6.43463123@news1.rdc1.sfba.home.com>...
> >Is having, "for Rx_Header_Data'size use 8*11;" better than pragma
> >pack? What is the rational?
>   What I want is an 11 byte record.  What a future maintainer might
> need to know is that it's an 11 byte record.  Perhaps "pragma pack"
> is a way to accomplish that, and perhaps it will be obvious to a
> future maintainer that such a record, when packed, is 11 bytes long,
> but it would take mental energy, and be susceptible to error, to be sure.
> If I didn't care about the layout, but just wanted to minimize storage,
> then using "pragma pack" would be easier.


OK. That's make the code more readable and maintainable.

Is "pragma pack" equivalent to "pragma optime (space)"?

Re: Size and pack

[Lutz Donnerhacke]

* Larry Kilgallen wrote:
>> Compile on Alpha and get BUS ERROR.
>
>Presumably that is a runtime rather than compilation time error.

Correct.

>You didn't say what model of Alpha, but older chips require
>certain instructions be aligned.  VMS deals with this through
>alignment fault handlers that fix up such problems at a penalty
>of about 100 instructions.  Perhaps you are on Unix or Linux
>(you didn't say in the body text).

OSF/1. Yep, and I added a pragma Atomic to provocate this effect.

Re: Size and pack

[Larry Kilgallen]

In article <slrn9tqd33.c7n.lutz@belenus.iks-jena.de>, lutz@iks-jena.de (Lutz Donnerhacke) writes:
> * Larry Kilgallen wrote:
>>> Compile on Alpha and get BUS ERROR.
>>
>>Presumably that is a runtime rather than compilation time error.
> 
> Correct.
> 
>>You didn't say what model of Alpha, but older chips require
>>certain instructions be aligned.  VMS deals with this through
>>alignment fault handlers that fix up such problems at a penalty
>>of about 100 instructions.  Perhaps you are on Unix or Linux
>>(you didn't say in the body text).
> 
> OSF/1. Yep, and I added a pragma Atomic to provocate this effect.

RM C.6 10

"It is illegal to apply either an Atomic or Atomic_Components pragma
 to an object or type if the implementation cannot support the indivisible
 reads and updates required by the pragma"

The Alpha 21064, 21064A and 21164 (at least) cannot support indivisible
reads and updates of non-aligned longwords or words.

That would seem to indicate that depending on the VMS fixups would not
be allowed with pragma Atomic either.   It certainly would not produce
what I think of as being correct code for the meaning of Atomic.  Some
other poster can comment regarding the meaning of "illegal" vs. other
pejoratives with regard to error messages generated :-)

Re: Size and pack

[tmoran]

>Is "pragma pack" equivalent to "pragma optime (space)"?
  I doubt it.  For instance, if there's just one instance of the record
(not an array), the extra code to get elements from a packed version is
quite likely bigger than the savings of packing.

Re: Size and pack

[Robert Dewar]

john.mccabe@emrad.com.nospam (John McCabe) wrote in message news:<3bc41989.4285341@news.demon.co.uk>...
> Your best bet would be to use as many representation attributes as are
> necessary. In general I would use both a representation clause and
> pragma pack 

No, that's pointless, if you use a complete rep clause, then it is
redundant to use pragma Pack since it won't have
any effect.

Re: Size and pack

[Robert Dewar]

john.mccabe@emrad.com.nospam (John McCabe) wrote in message news:<3bc55c38.3322217@news.demon.co.uk>...
> 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.

This is FUD, the above rewriting accomplishes
nothing and is wholly undesirable. No confusion
arises in either case on a byte addressed machine,
and on a word addressed machine, neither form is
likely to give you what you want.

Re: Size and pack

[Robert Dewar]

"Smark" <not.provided@all.com> wrote in message news:<Id5C7.31176$pb4.15277558@news2.rdc2.tx.home.com>...
> As you indicated in another post, neither pragma pack nor a rep clause
> gives you what you want.  This is because neither of these will violate
> the alignment rules for a given type. 


This is incorrect (I must say a thread with the above
subject is almost designed to attract a fair number of
incorrect posts, and the expectation is met here, this
is tricky stuff).

Re: Size and pack

[Robert Dewar]

"Smark" <not.provided@all.com> wrote in message news:<EohC7.32898$pb4.16108301@news2.rdc2.tx.home.com>...
> The problem was that this rep clause will not work, 
> because Log_Num must
> be aligned to a 4-byte boundary.

This is simply wrong.

> Some compilers will silently ignore your
> rep clause, I believe GNAT will tell you it can't do it.

Belief is not a good substitute for knowledge :-)
This is also wrong

Re: Size and pack

[Robert Dewar]

lutz@iks-jena.de (Lutz Donnerhacke) wrote in message news:<slrn9tq9mi.nt.lutz@taranis.iks-jena.de>...
> Compile on Alpha and get BUS ERROR.

If this happens it is a bug (this bug is certainly not
present in the current version of GNAT). Who knows about
other compilers, or earlier versions. If a compiler accepts
a rep clause, it is supposed to generate working code for
that rep clause.

Re: Size and pack

[Robert Dewar]

lutz@iks-jena.de (Lutz Donnerhacke) wrote in message news:<slrn9tqd33.c7n.lutz@belenus.iks-jena.de>...
> OSF/1. Yep, and I added a pragma Atomic to provocate this effect.

Again, this is a bug, if the compiler accepts a set of
declarations, it must generate proper code.

Re: Size and pack

[Robert Dewar]

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<X7Zq0LolyKes@eisner.encompasserve.org>...
> That would seem to indicate that depending on the VMS fixups would not
> be allowed with pragma Atomic either.  

That would be fine if the fixup routine runs in a non-preemptible
manner. There is no requirement that Atomic
generate a single instruction (a conforming implementation
could even take an OS lock to implement Atomic, though this
is certainly not an intended implementation approach).

Re: Size and pack

[Larry Kilgallen]

In article <5ee5b646.0110301800.55e5d2d7@posting.google.com>, dewar@gnat.com (Robert Dewar) writes:
> lutz@iks-jena.de (Lutz Donnerhacke) wrote in message news:<slrn9tqd33.c7n.lutz@belenus.iks-jena.de>...
>> OSF/1. Yep, and I added a pragma Atomic to provocate this effect.
> 
> Again, this is a bug, if the compiler accepts a set of
> declarations, it must generate proper code.

Is there no way for GNAT to generate code specific to the newer
Alpha chips ?  If that were done and the code were run on an
older Alpha chip, I would expect a runtime error.

Re: Size and pack

[John McCabe]

On 30 Oct 2001 17:50:14 -0800, dewar@gnat.com (Robert Dewar) wrote:

>john.mccabe@emrad.com.nospam (John McCabe) wrote in message news:<3bc41989.4285341@news.demon.co.uk>...
>> Your best bet would be to use as many representation attributes as are
>> necessary. In general I would use both a representation clause and
>> pragma pack 
>
>No, that's pointless, if you use a complete rep clause, then it is
>redundant to use pragma Pack since it won't have
>any effect.

Interesting you should say that, because it conflicts with your
opinion from a previous, very similar comment I made some time ago! It
would appear your technical opinions change with the weather!

Re: Size and pack

[Jeff Creem]

OK.. I know I am going to regret this since whenever I question Robert I
usually am wrong however
without using the complete context of this thread, I believe Roberts
statement is actually
a little too broad. There ARE indeed times when you want a pragma pack and a
rep spec. Not for the record case but for arrays of items that have been rep
spec'ed.

for example, the code fragment

type My_Type is range 0 .. 3;
for My_Type'size use 2;

type My_Array is array (1 .. 4) of My_Type;
pragma Pack (My_Array); -- Without this the following could fail
for My_Array'size use 8;


The pragma pack is needed I believe because the rep spec on My_Array can
be rejected without it (At least it has been rejected by some compilers and
I forget
the exact rule but it had something to do with the final rep spec not being
allowed to
change the layout of the items within the array).

Having said that VADS used to compile this without the pragma pack. Green
Hills did not.
I *THINK* GNAT does allow it to go through without the rep spec for several
versions now.


"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0110301750.38ba5bfd@posting.google.com...
> john.mccabe@emrad.com.nospam (John McCabe) wrote in message
news:<3bc41989.4285341@news.demon.co.uk>...
> > Your best bet would be to use as many representation attributes as are
> > necessary. In general I would use both a representation clause and
> > pragma pack
>
> No, that's pointless, if you use a complete rep clause, then it is
> redundant to use pragma Pack since it won't have
> any effect.

Re: Size and pack

[Adrian Hoe]

"Jeff Creem" <jeff@thecreems.com> wrote in message news:<nHRD7.162473$vq.40258001@typhoon.ne.mediaone.net>...
> OK.. I know I am going to regret this since whenever I question Robert I
> usually am wrong however
> without using the complete context of this thread, I believe Roberts
> statement is actually
> a little too broad. There ARE indeed times when you want a pragma pack and a
> rep spec. Not for the record case but for arrays of items that have been rep
> spec'ed.
> 
> for example, the code fragment
> 
> type My_Type is range 0 .. 3;
> for My_Type'size use 2;
> 
> type My_Array is array (1 .. 4) of My_Type;
> pragma Pack (My_Array); -- Without this the following could fail
> for My_Array'size use 8;
> 
> 
> The pragma pack is needed I believe because the rep spec on My_Array can
> be rejected without it (At least it has been rejected by some compilers and
> I forget
> the exact rule but it had something to do with the final rep spec not being
> allowed to
> change the layout of the items within the array).
> 
> Having said that VADS used to compile this without the pragma pack. Green
> Hills did not.
> I *THINK* GNAT does allow it to go through without the rep spec for several
> versions now.


But, why the differenct implementation by these compilers' vendors? I
thought Ada is a standardized language regardless of platforms. Of
course, a problem like whether to use "pragma pack" or not in the
above Jeff's example "supposed" not to arise if Ada is standardized.

Oh... I am getting quite confusing now, and not to mention Ada
newbies!



> 
> "Robert Dewar" <dewar@gnat.com> wrote in message
> news:5ee5b646.0110301750.38ba5bfd@posting.google.com...
> > john.mccabe@emrad.com.nospam (John McCabe) wrote in message
>  news:<3bc41989.4285341@news.demon.co.uk>...
> > > Your best bet would be to use as many representation attributes as are
> > > necessary. In general I would use both a representation clause and
> > > pragma pack
> >
> > No, that's pointless, if you use a complete rep clause, then it is
> > redundant to use pragma Pack since it won't have
> > any effect.

Re: Size and pack

[Jeff Creem]

See..I knew it was too early when I wrote that. I checked and GNAT rejects
it as well without the pragma pack.
VADS allowed it however that was an Ada 83 implementation.

In any case I stand by my basic premise that Roberts response was correct
when
limited to the scope of the thread (which was talking about record rep
clauses) however
it was too broad when taken out of context since the pragma pack should
indeed
by used on the array when one wants to pack the items of the array.


As for the "Standardization" troll comment..There are many things in the
standard
that are not directly specified or are specified in terms of dependencies on
the
host architecture. (Word size, etc).. This is not Java. There is no standard
Ada
virtual machine that forces all applications to run 5-30 times slower than
a native implementation (see I can troll too!).


"Adrian Hoe" <byhoe@greenlime.com> wrote in message
news:9ff447f2.0110311758.2be52637@posting.google.com...
> "Jeff Creem" <jeff@thecreems.com> wrote in message
news:<nHRD7.162473$vq.40258001@typhoon.ne.mediaone.net>...
> > OK.. I know I am going to regret this since whenever I question Robert I
> > usually am wrong however
> > without using the complete context of this thread, I believe Roberts
> > statement is actually
> > a little too broad. There ARE indeed times when you want a pragma pack
and a
> > rep spec. Not for the record case but for arrays of items that have been
rep
> > spec'ed.
> >
> > for example, the code fragment
> >
> > type My_Type is range 0 .. 3;
> > for My_Type'size use 2;
> >
> > type My_Array is array (1 .. 4) of My_Type;
> > pragma Pack (My_Array); -- Without this the following could fail
> > for My_Array'size use 8;
> >
> >
> > The pragma pack is needed I believe because the rep spec on My_Array can
> > be rejected without it (At least it has been rejected by some compilers
and
> > I forget
> > the exact rule but it had something to do with the final rep spec not
being
> > allowed to
> > change the layout of the items within the array).
> >
> > Having said that VADS used to compile this without the pragma pack.
Green
> > Hills did not.
> > I *THINK* GNAT does allow it to go through without the rep spec for
several
> > versions now.
>
>
> But, why the differenct implementation by these compilers' vendors? I
> thought Ada is a standardized language regardless of platforms. Of
> course, a problem like whether to use "pragma pack" or not in the
> above Jeff's example "supposed" not to arise if Ada is standardized.
>
> Oh... I am getting quite confusing now, and not to mention Ada
> newbies!
>
>
>
> >
> > "Robert Dewar" <dewar@gnat.com> wrote in message
> > news:5ee5b646.0110301750.38ba5bfd@posting.google.com...
> > > john.mccabe@emrad.com.nospam (John McCabe) wrote in message
> >  news:<3bc41989.4285341@news.demon.co.uk>...
> > > > Your best bet would be to use as many representation attributes as
are
> > > > necessary. In general I would use both a representation clause and
> > > > pragma pack
> > >
> > > No, that's pointless, if you use a complete rep clause, then it is
> > > redundant to use pragma Pack since it won't have
> > > any effect.

Re: Size and pack

[Jeffrey Carter]

Jeff Creem wrote:
> 
> a little too broad. There ARE indeed times when you want a pragma pack and a
> rep spec. Not for the record case but for arrays of items that have been rep
> spec'ed.
> 
> for example, the code fragment
> 
> type My_Type is range 0 .. 3;
> for My_Type'size use 2;
> 
> type My_Array is array (1 .. 4) of My_Type;
> pragma Pack (My_Array); -- Without this the following could fail
> for My_Array'size use 8;

Generally a compiler would use 4 bytes (or storage units) for My_Array,
and without something to tell the compiler to use less storage for each
component the size clause should be rejected. However, one can replace
the pragma Pack with

for My_Array'Component_Size use My_Type'Size;
for My_Array'Size use My_Array'Length * My_Type'Size;

to obtain the same effect without relying on Pack, which is allowed to
be ignored.

-- 
Jeff Carter
"We call your door-opening request a silly thing."
Monty Python & the Holy Grail

Re: Size and pack

[Matthew Heaney]

"Adrian Hoe" <byhoe@greenlime.com> wrote in message
news:9ff447f2.0110311758.2be52637@posting.google.com...
> "Jeff Creem" <jeff@thecreems.com> wrote in message
news:<nHRD7.162473$vq.40258001@typhoon.ne.mediaone.net>...
> > for example, the code fragment
> >
> > type My_Type is range 0 .. 3;
> > for My_Type'size use 2;
> >
> > type My_Array is array (1 .. 4) of My_Type;
> > pragma Pack (My_Array); -- Without this the following could fail
> > for My_Array'size use 8;
> >
> >
> > The pragma pack is needed I believe because the rep spec on My_Array can
> > be rejected without it

Why aren't you (Jeff) specifying the array component size?

for My_Array'Component_Size use 2;

Won't that eliminate the need for the pragma Pack?

Furthermore, isn't the size clause for My_Type redundent?  The size of a
type is the number of bits needed to represent all values in the type, which
is 2 bits.

Re: Size and pack

[Robert Dewar]

"Jeff Creem" <jeff@thecreems.com> wrote in message news:<nHRD7.162473$vq.40258001@typhoon.ne.mediaone.net>...

> Not for the record case but for arrays of items that have 
> been rep spec'ed.
> 
> for example, the code fragment
> 
> type My_Type is range 0 .. 3;
> for My_Type'size use 2;
> 
> type My_Array is array (1 .. 4) of My_Type;
> pragma Pack (My_Array); -- Without this the following 
> could fail for My_Array'size use 8;

Well yes, but this array has NOT been "rep spec'ed", you
did not specify a component size. That's what corresponds
to specifying a full record clause. So if you want to control exactly
what happens, a better form of the above
is:

   type My_Type is range 0 .. 3;
   for My_Type'Size use 2;

   type My_Array is array (1 .. 4) of My_Type;
   for My_Array'Component_Size use 2;
   for My_Array'Size use 8;

the last clause is redundant, but often useful for
documentation emphasis, but most certainly a pragma
Pack is redundant in this case.

> I *THINK* GNAT does allow it to go through without the 
> rep spec for several versions now.

You think wrong, the size clause alone should NOT change
the layout, and in GNAT it will not.

Use pack if you just generally want to save space (as in
the record case). Use component_Size if you want to precisely control
the size of components.

Re: Size and pack

[Marin David Condic]

It ought to be observed that it is not possible for any language to be 100%
portable across all platforms and in all cases - ESPECIALLY once you start
tinkering with machine specific things like data representations. Once you
take off the pannel that is marked "Caution! No User Servicable Parts
Inside." all bets are off.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Jeff Creem" <jeff@thecreems.com> wrote in message
news:Hw2E7.163731$vq.40606082@typhoon.ne.mediaone.net...
>
> As for the "Standardization" troll comment..There are many things in the
> standard
> that are not directly specified or are specified in terms of dependencies
on
> the
> host architecture. (Word size, etc).. This is not Java. There is no
standard
> Ada
> virtual machine that forces all applications to run 5-30 times slower than
> a native implementation (see I can troll too!).
>

Re: Size and pack

[Jeff Creem]

I tend to avoid 'component size since a lot of my code needs to compile
on Ada 83 and Ada 95. The pragma pack followed by the confirmatory
'size clause on the overall array should force the compiler to do what I
want and
if it does not (because it ignores the pragma) it will reject the final rep
spec on the array.

So the final 'size is not redundant.


"Matthew Heaney" <mheaney@on2.com> wrote in message
news:tu1hjutp4bdgf7@corp.supernews.com...
>
> "Adrian Hoe" <byhoe@greenlime.com> wrote in message
> news:9ff447f2.0110311758.2be52637@posting.google.com...
> > "Jeff Creem" <jeff@thecreems.com> wrote in message
> news:<nHRD7.162473$vq.40258001@typhoon.ne.mediaone.net>...
> > > for example, the code fragment
> > >
> > > type My_Type is range 0 .. 3;
> > > for My_Type'size use 2;
> > >
> > > type My_Array is array (1 .. 4) of My_Type;
> > > pragma Pack (My_Array); -- Without this the following could fail
> > > for My_Array'size use 8;
> > >
> > >
> > > The pragma pack is needed I believe because the rep spec on My_Array
can
> > > be rejected without it
>
> Why aren't you (Jeff) specifying the array component size?
>
> for My_Array'Component_Size use 2;
>
> Won't that eliminate the need for the pragma Pack?
>
> Furthermore, isn't the size clause for My_Type redundent?  The size of a
> type is the number of bits needed to represent all values in the type,
which
> is 2 bits.
>
>
>
>
>

Re: Size and pack

[Robert Dewar]

"Jeff Creem" <jeff@thecreems.com> wrote in message news:<yDgE7.1022$kw.476665@typhoon.ne.mediaone.net>...
> I tend to avoid 'component size since a lot of my code needs to compile
> on Ada 83 and Ada 95. The pragma pack followed by the confirmatory
> 'size clause on the overall array should force the compiler to do what I
> want and
> if it does not (because it ignores the pragma) it will reject the final rep
> spec on the array.
> 
> So the final 'size is not redundant.

Right, my point was that the final 'Size is redundant *if*
you specify the full representation, but of course if you
omit the Component_Size clause you have not fulfilled this
precondition.