- High_Order_First when the bit 0 is the most significant bit
- Low_Order_First when the bit 0 is the least significant bit
The constant System.Default_Bit_Order represents the native bit numbering of the platform.
The following two sets of representation clauses specify the same register layout in any machine / compiler:
type Device_Register is record Ready : Status_Flag; Error : Error_Flag; Data : Unsigned_16; end record; for Device_Register use record Ready at 0 range 0 .. 0; Error at 0 range 1 .. 1; -- Reserved bits Data at 0 range 16 .. 31; end record; for Device_Register'Size use 32; for Device_Register'Bit_Order use System.Low_Order_First; pragma Atomic (Device_Register);
If the bit order is modified, the bit numbering of all the elements of the record representation clause must be reversed:
type Device_Register is record Ready : Status_Flag; Error : Error_Flag; Data : Unsigned_16; end record; for Device_Register use record Ready at 0 range 31 .. 31; -- Bit numbering has changed Error at 0 range 30 .. 30; -- Bit numbering has changed -- Reserved bits Data at 0 range 0 .. 15; -- Bit numbering has changed (but byte order is not affected) end record; for Device_Register'Size use 32; for Device_Register'Bit_Order use System.High_Order_First; -- Reverse bit order pragma Atomic (Device_Register);
Both can be interchangeably used in the same machine. But note that in two machines with different endianness the Data field will have the native byte order regardless of the bit order specified in the representation clauses.
The 'Bit_Order attribute is not intended to convert data between a big-endian and a little-endian machine (it affects bit numbering, not byte order). The compiler will not generate code to reorder multi-byte fields when a non-native bit order is specified.
- Note that when the ARM talks about "big endian" and "litte endian" in the definition of the 'Bit_Order attribute it really means bit endianness, not byte endianness. (Nowadays the term endianness is usually reserved for talking about byte order, although it can also be used for bit numbering.) Thus, in this context, when the ARM says "little endian" it refers to "LSB 0", and when it says "big endian" this is the same as "MSB 0":
«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.» [LRM, §13.5.3(2)]
- AI95-00133-01 (1996-05-07). "Controlling bit ordering". Class: binding interpretation. Ada Rapporteur Group. http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ais/ai-00133.txt?rev=1.17. "Bit_Order clauses are concerned with the numbering of bits and not concerned with data flipping interoperability."
- ISO/IEC 8652:2007. "13.5.3 Bit Ordering (9/2)". Ada 2005 Reference Manual. http://www.adaic.com/standards/05rm/html/RM-13-5-3.html#I4589. Retrieved 2008-06-02. "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."
- Thomas Quinot (January 2013). "Gem #140: Bridging the Endianness Gap". AdaCore. http://www.adacore.com/adaanswers/gems/gem-140-bridging-the-endianness-gap/. Retrieved 2013-01-31. "the order in which the bytes that constitute machine scalars are written to memory is not changed by the Bit_Order attribute -- only the indices of bits within machine scalars are changed."
- Available in Ada 95 and Ada 2005.
'Bit_Order is a portability aid between different compilers. In Ada 83 the bit numbering in representation clauses was implementation dependent so compilers can choose for each platform its natural ordering. However, this introduced portability problems between compilers.
It is a standard attribute since Ada 95, so it must be accepted by all Ada 95 and Ada 2005 compilers. Compilers are suggested (but not required) to support the non-default bit order. GNAT supports both bit numberings, but recent versions give a warning if the non-default order is specified.
Although this attribute can be a portability aid between different platforms, the byte order of some (multibyte) fields will not probably be the same in machines with a different endianness.
Record representation clauses are a unique feature of the Ada language as far as the authors know, so there is no need to have a feature similar to attribute 'Bit_Order in other programming languages. It is common practice in other programming languages to use masks and bit operations explicitly, thus the native bit numbering must always be used.
- Ada Programming
- Ada Programming/Attributes
- Ada Programming/Attributes/'Position
- Ada Programming/Attributes/'First_Bit
- Ada Programming/Attributes/'Last_Bit
Ada Reference ManualEdit
Ada 95 RationaleEdit
References and notesEdit
- ISO/IEC 8652:1987. "13.4 Record Representation Clauses". Ada 83 Reference Manual. http://archive.adaic.com/standards/83lrm/html/lrm-13-04.html#13.4. Retrieved 2008-12-20. "The range defines the bit positions of the storage place, relative to the storage unit. The first storage unit of a record is numbered zero. The first bit of a storage unit is numbered zero. The ordering of bits in a storage unit is machine_dependent and may extend to adjacent storage units."
- Norman H. Cohen (January 1994). "Endian-independent record representation clauses". ACM SIGAda Ada Letters (New York, NY, USA: Association for Computing Machinery) XIV (1): 27–29. ISSN 1094-3641. http://researchweb.watson.ibm.com/people/n/ncohen/EndianIndepRecRepClauses.pdf. Retrieved 2008-12-20.
- Randal P. Andress (September 2005). "Wholesale byte reversal of the outermost Ada record object to achieve endian independence for communicated data types". ACM SIGAda Ada Letters (New York, NY, USA: Association for Computing Machinery) XXV (3): 19–27. ISSN 1094-3641. http://www.sigada.org/ada_letters/sept2005/Endian-Independent%20Paper.pdf. Retrieved 2008-12-20.