Version 1.1 of ais/ai-00133.txt

Unformatted version of ais/ai-00133.txt version 1.1
Other versions for file ais/ai-00133.txt

!standard 13.05.03 (00)          98-03-27 AI95-00133/02
!class binding interpretation 96-05-07
!status work item 96-05-07
!status received 96-05-07
!priority Medium
!difficulty Medium
!subject controlling bit ordering
!summary 98-03-27
The Bit_Order clause is intended to provide compiler uniformity on a single machine. If there is one storage element per word, then it is not necessarily clear which direction the bits should be ordered in; the programmer may use Bit_Order to specify it.
If there are more than one storage elements per word, then Bit_Order follows the addressing order by default, and the implementation need not support anything else. If the implementation chooses to support (all) Bit_Order clauses on such a machine, then a single component can end up being allocated in a noncontiguous set of bits.
!question 98-03-27
What problem is the Bit_Order attribute supposed to solve? Is is intended to solve:
1) the "compiler uniformity problem" where a single program on
a single processor wishes to use unchecked_conversion to convert a scalar (e.g. float) object to a record type (e.g. in order to extract the sign, exponent, and mantissa), and wishes to use a single portable record representation clause regardless of the default endianness of the target computer;
or
2) the "data interoperability problem" where two processors with
different bit orders need to access shared memory, files, devices, or network channels, so one processor has to do cumbersome byte flipping?
!recommendation 98-03-27
(See Summary.)
!wording 96-05-07
!discussion 96-05-07
!appendix

!section 13.5.3(00)
!subject controlling bit ordering
!reference RM95-13.5.3
!from Dan Eilers 96-04-24
!reference 96-5511.a Dan Eilers  96-4-24>>
!discussion

There seems to be confusion (as evidenced by recent c.l.a. discussion)
as to which problem the Bit_Order attribute is supposed to solve.
Is is intended to solve:
   1) the "compiler uniformity problem" where a single program on
      a single processor wishes to use unchecked_conversion to
      convert a scalar (e.g. float) object to a record type (e.g.
      in order to extract the sign, exponent, and mantissa), and
      wishes to use a single portable record representation clause
      regardless of the default endianness of the target computer;
or
   2) the "data interoperability problem" where two processors with
      different bit orders need to access shared memory, files,
      devices, or network channels, so one processor has to do
      cumbersome byte flipping?

Problem #1 was accepted as Revision Requirement 2.4 "Controlling
Implementation-Dependent Choices", referring to RR-0137 "Standardize
bit storage/order conventions" and RR-0411 "Express record representation
clauses in a machine-independent way".

Problem #2 was accepted in the Aug 27, 1990 Draft 3.3 as Revision
Requirement 6.2 "Data Interoperability" under Study Topic 25.1
"Data Interoperability":
     For example, there is no control over the bit/byte ordering --
     such control is required in order to deal with the conflicting
     representations between "little-endian" and "big-endian"
     representations.
However, the endianness aspect of Revision Requirement 6.2 was dropped
in the final Revision Requirements document.

Evidence that Problem #1 was intended is: that it is the one
that was accepted as a final requirement; it is the easiest
of the two solutions to implement; and 13.5.3 says nothing about
byte flipping.  Presumably problem #1 is implemented simply
by counting bit offsets from the end of the record rather
than from the front of the record.

Evidence that Problem #2 was intended is that support for
nondefault bit ordering is optional, apparently due to presumed
implementation difficulties.

Note that it isn't possible for a single attribute to solve
both problems, since the solutions are mutually exclusive in
the case where a record field spans a byte boundary.  Such a
field would get flipped for solution #2, and not in Solution #1.

        -- Dan Eilers

****************************************************************

Questions? Ask the ACAA Technical Agent