13.5.3 Bit Ordering
[The Bit_Order attribute specifies the interpretation
of the storage place attributes.]
Reason: The intention is to provide uniformity
in the interpretation of storage places across implementations on a particular
machine by allowing the user to specify the Bit_Order. It is not intended
to fully support data interoperability across different machines, although
it can be used for that purpose in some situations.
We can't require all implementations on a given machine to use the same
bit ordering by default; if the user cares, a pragma
can be used to force all implementations to use the same bit ordering.
A bit ordering is a method of
interpreting the meaning of the storage place attributes.
[(known in the vernacular as “big endian”)] means that the
first bit of a storage element (bit 0) is the most significant bit (interpreting
the sequence of bits that represent a component as an unsigned integer
[(known in the vernacular as “little endian”)] means the
opposite: the first bit is the least significant.
For every specific
record subtype S, the following attribute is defined:
Denotes the bit ordering for
the type of S. The value of this attribute is of type System.Bit_Order.
Bit_Order may be specified for
specific record types via an attribute_definition_clause
the expression of such a clause shall be static.
If Word_Size = Storage_Unit, the default bit ordering
is implementation defined. If Word_Size > Storage_Unit, the default
bit ordering is the same as the ordering of storage elements in a word,
when interpreted as an integer.
Implementation defined: If Word_Size
= Storage_Unit, the default bit ordering.
Ramification: Consider machines whose
Word_Size = 32, and whose Storage_Unit = 8. Assume the default bit ordering
applies. On a machine with big-endian addresses, the most significant
storage element of an integer is at the address of the integer. Therefore,
bit zero of a storage element is the most significant bit. On a machine
with little-endian addresses, the least significant storage element of
an integer is at the address of the integer. Therefore, bit zero of a
storage element is the least significant bit.
The storage place attributes of a component of a
type are interpreted according to the bit ordering of the type.
recommended level of support for the nondefault bit ordering is:
The If Word_Size =
Storage_Unit, then the
implementation should support the nondefault
bit ordering in addition to the default bit ordering.
The If Word_Size =
implementation should support both bit orderings.
don't push for support of the nondefault bit ordering when Word_Size
> Storage_Unit (except of course for upward compatibility with a preexisting
implementation whose Ada 83 bit order did not correspond to the required
Ada 95 default bit order), because implementations
to support storage positions that cross storage element boundaries when
Word_Size > Storage_Unit but the definition
of the storage place attributes for the nondefault bit order ensures
that such. Such
be split into two or three pieces.
Thus, there is no significant implementation burden to supporting the
nondefault bit order, given that the set of machine scalars is implementation-defined if the nondefault bit ordering is used, which could be onerous to support.
However, if Word_Size = Storage_Unit, there might not be a natural bit
ordering, but the splitting problem need not occur
The recommended level of support for
the nondefault bit ordering should be followed.
Bit_Order clauses make it possible to write record_representation_clauses
that can be ported between machines having different bit ordering. They
do not guarantee transparent exchange of data between such machines.
Extensions to Ada 83
The Bit_Order attribute
is new to Ada 95.
Wording Changes from Ada 95
We now suggest that all implementations support
the nondefault bit order.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe