Re: Size and pack

[dewar@gnat.com (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