Re: Size and pack

[Mark Johnson <Mark_H_Johnson@Raytheon.com>]

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