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.
{
AI95-00114-01}
We can't require all implementations on a given machine to use the same
bit ordering by default; if the user cares, a Bit_Order
attribute_definition_clause
can be used to force all implementations to use the same bit ordering.
Static Semantics
{bit ordering}
A bit ordering is a method of interpreting the meaning
of the storage place attributes.
{High_Order_First}
{big endian}
{endian (big)}
High_Order_First [(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 value).
{Low_Order_First}
{little endian}
{endian (little)}
Low_Order_First [(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:
S'Bit_Order
Denotes the bit ordering for
the type of S. The value of this attribute is of type System.Bit_Order.
{specifiable (of Bit_Order for record
types and record extensions) [partial]} {Bit_Order
clause} 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.
{byte
sex: See ordering of storage elements in a word} 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.
Implementation Advice
{recommended
level of support (bit ordering) [partial]} The
recommended level of support for the nondefault bit ordering is:
{
AI95-00133-01}
The implementation should support the nondefault bit ordering in addition
to the default bit ordering.
Ramification: {
AI95-00133-01}
The implementation should support both bit orderings. Implementations
are required 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
storage positions will not 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.
Implementation Advice: The recommended
level of support for the nondefault bit ordering should be followed.
13 {
AI95-00133-01}
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
{
extensions to Ada 83}
The
Bit_Order attribute is new to Ada 95.
Wording Changes from Ada 95
{
AI95-00133-01}
We now suggest that all implementations support the nondefault bit order.
Sponsored by Ada-Europe