Re: GNAT Ada for DOS - Reading Integers Problem

[ncohen@watson.ibm.com (Norman H. Cohen)]

In article <dewar.824906918@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes: 

|> Norman says
|>
|> "No, the purpose of the 'Bit_Order attribute is not to perform
|> big-endian/little-endian data conversion at run-time, but to assert that
|> bit numbers in record-representation clauses should be interpreted at
|> compile time according to either big-endian or little-endian conventions."
|>
|> That's wrong, if a compiler DOES allow this compile time control, then
|> normal change-of-representation coding (i.e. have two derived types, one
|> with one bit order and one with the other, and use conversions to flip
|> between the two) should work fine.

What does the change-of-representation approach have to do with the
'Bit_Order attribute?  You could accomplish that even with Ada 83: 

   type Byte is range 0 .. 255;
   for Byte'Size use 8;

(The names Low and High suggest that Half_Word is an LE representation
and Byte_Swapped_Half_Word is a BE representation, but the example is
symmetric.)

RM95-13.5.3(1) is quite clear about the 'Bit_Order attribute:  "The
Bit_Order attribute specifies the interpretation of the storage place
attributes."  (The storage-place attributes are R.C'Position,
R.C'First_Bit, and R.C'Last_Bit.  The values in a record-representation
clause determine the values of these attributes, as described in
RM95-13.5.1(13).)

|> Implementing the unnatural order is non-trivial (and implementing the
|> above change of representation even more non-trivial). Furthermore the
|> RM does not require this feature be implemented, so don't count on it
|> being available!

What Robert means is that support for the nondefault value for 'Bit_Order
is not required by the RM (for any of the most common architectures).
However, the representation clauses above, which don't use the 'Bit_Order
attribute, ought to work on any machine with 8-bit bytes.

Perhaps Robert is suggesting that the same effect could be achieved by
writing

   type Half_Word is
      record
         Low  : Byte;
         High : Byte;
      end record;

   for Half_Word'Bit_Order use Low_Order_First;

   for Half_Word use
      record
         Low  at 0 range 0 .. 7;
         High at 0 range 8 .. 15;
      end record;

   type Byte_Swapped_Half_Word is new Half_Word;

   for Byte_Swapped_Half_Word'Bit_Order use High_Order_First;

causing Byte_Swapped_Half_Word to inherit the literal text

    Low  at 0 range 0 .. 7;
    High at 0 range 8 .. 15;

from its parent's record representation clause, but to interpret that
text big-endianly instead of little-endianly!  This is certainly a
creative interpretation, but I can't believe it is what the Founding
Fathers intended.  RM95-13.1(15) states that "A derived type inherits
each type-related aspect of its parent type that was directly specified
before the declaration of the derived type ...," but surely it is the
actual layout of the parent type rather than the program text describing
that layout that should be considered an "aspect of representation".
After all, if the record-representation clause is omitted, the program
text will cease to exist, but the parent type will still have some
default layout.

(Fortunately, the Founding Fathers follow this newsgroup and can provide
a definitive answer about their Original Intent.)

--
Norman H. Cohen    ncohen@watson.ibm.com