Annotated Ada Reference ManualLegal Information
Contents   Index   References   Search   Previous   Next 

13.5.3 Bit Ordering

1
[The Bit_Order attribute specifies the interpretation of the storage place attributes.] 
1.a
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.
1.b/2
{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 pragma Bit_Order attribute_definition_clause can be used to force all implementations to use the same bit ordering.

Static Semantics

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 most significant bit (interpreting the sequence of bits that represent a component as an unsigned integer value). Low_Order_First [(known in the vernacular as “little endian”)] means the opposite: the first bit is the least significant.
3
For every specific record subtype S, the following attribute is defined: 
4
S'Bit_Order
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.
4.a/3
Aspect Description for Bit_Order: Order of bit numbering in a record_representation_clause.
5
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.
5.a
Implementation defined: If Word_Size = Storage_Unit, the default bit ordering.
5.b
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. 
6
The storage place attributes of a component of a type are interpreted according to the bit ordering of the type. 
6.a
Ramification: This implies that the interpretation of the position, first_bit, and last_bit of a component_clause of a record_representation_clause obey the bit ordering given in a representation item. 

Implementation Advice

7
The recommended level of support for the nondefault bit ordering is: 
8/2
{AI95-00133-01} The If Word_Size = Storage_Unit, then the implementation should support the nondefault bit ordering in addition to the default bit ordering. 
8.a/2
Ramification: {AI95-00133-01} The If Word_Size = Storage_Unit, the implementation should support both bit orderings. Implementations We 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 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. 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 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
8.b/2
Implementation Advice: The recommended level of support for the nondefault bit ordering should be followed.
NOTES
9/2
17  {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

9.a
The Bit_Order attribute is new to Ada 95. 

Wording Changes from Ada 95

9.b/2
{AI95-00133-01} We now suggest that all implementations support the nondefault bit order. 

Contents   Index   References   Search   Previous   Next 
Ada-Europe Ada 2005 and 2012 Editions sponsored in part by Ada-Europe