Re: GNAT Ada for DOS - Reading Integers Problem

Re: GNAT Ada for DOS - Reading Integers Problem

[Dave Haverkamp]

In article <tgmDMwoGx.B04@netcom.com>, tgm@netcom.com (Thomas G. McWilliams) writes:
|> William Paul Berriss (strberis) wrote:
|> : When reading in the peppers.ras file it gets the nymbers form the header BUT
|> : instead of 512 it shows (on the screen) 131072, and instead of 24 it shows 
|> : something huge like 6291456.  All these 'wrong' numbers can be made from
|> : other numbers, e.g. 131072 is 256 times 512.  It should have been 512!
|> 
|> I suspect that this is partly an endian problem. Sun is big endian and
|> DOS is little endian.
|> 

For ada95 look at the "Bit_Order" attribute.

     for T'Bit_Order use Highest_Bit_First;

     or

     for T'Bit_Order use Lowest_Bit_First;


I'm not sure this will help in your application.  But you definitely
need to flip the bits around.

-- 
David Haverkamp 
dahaverk@cca.rockwell.com
-- 
David Haverkamp 
dahaverk@cca.rockwell.com

Re: GNAT Ada for DOS - Reading Integers Problem

[Norman H. Cohen]

In article <Dn33HL.ICr@lazrus.cca.rockwell.com>, dahaverk@cca.rockwell.com
(Dave Haverkamp) writes: 

|> For ada95 look at the "Bit_Order" attribute.
|>
|>      for T'Bit_Order use Highest_Bit_First;
|>
|>      or
|>
|>      for T'Bit_Order use Lowest_Bit_First;
|>
|>
|> I'm not sure this will help in your application.  But you definitely
|> need to flip the bits around.

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.

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

Re: GNAT Ada for DOS - Reading Integers Problem

[Robert Dewar]

Norman said  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.


Absolutely, that is what Robert is suggesting, and I can't manage to
read the intent of the RM any other way. When ytou derive, you inherit
the rep clauses, and then you can override any or all of them, and the
result is whatever you get from the mixture of inherited and overridden
rep clauses.

Now of course the above example is boring, since there are no fields
overlapping storage boundaries (and is thus incidentally trivial to
implement). The situation gets much more interesting with fields
that overlap storage boundaries, because then the non-default order
results in non-contiguous fields that are a real pain to implement.

Re: GNAT Ada for DOS - Reading Integers Problem

[Robert Dewar]

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.

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!

Re: GNAT Ada for DOS - Reading Integers Problem

[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

Re: GNAT Ada for DOS - Reading Integers Problem

[Robert A Duff]

In article <4gfsuq$10f5@watnews1.watson.ibm.com>,
Norman H. Cohen <ncohen@watson.ibm.com> wrote:
>   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!

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

Well, *this* Founding Father can't.  I have to admit that I never
thought about this particular example.

However, I think that's what the RM says -- you inherit the record rep
clause, but you override the bit order.  That seems like the only
reasonable intepretation.

Note that the above is illegal if there are any inherited subprograms
lurking around (which is quite often the case).

- Bob

Re: GNAT Ada for DOS - Reading Integers Problem

[Robert Dewar]

"Would it not be pretty easy to implement, if you restrict it to
components that exactly fit in 1, 2, or 4 bytes -- that is, avoid the
cases that cause non-contiguous bit fields?  These are probably the
cases people want most of the time anyway.

It is correct that the RM does not require the feature.  (Actually, it
*does* require the feature on machines where the storage element is a
word -- but such machines aren't too common anymore.)"

Yes, it would be much easier to implement with this restriction, but in
my experience, this would be a very significant restriction.
\x1adp

Re: GNAT Ada for DOS - Reading Integers Problem

[Robert Dewar]

Bob Duff said, replying to Norm Cohen:

">    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!

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

Well, *this* Founding Father can't.  I have to admit that I never
thought about this particular example.

However, I think that's what the RM says -- you inherit the record rep
clause, but you override the bit order.  That seems like the only
reasonable intepretation."

Robert replies

Well that's a surprise, I always read the RM this way, and assumed that
the whole point of Bit_Order was to provide this capability. Like Bob,
I certainly can't see any other way to read the RM :-)

Re: GNAT Ada for DOS - Reading Integers Problem

[Tore Joergensen]

William Paul Berriss (strberis) wrote:
[...snip...]
: What it does is this:
: When reading in the peppers.ras file it gets the nymbers form the header BUT
: instead of 512 it shows (on the screen) 131072, and instead of 24 it shows 
: something huge like 6291456.  All these 'wrong' numbers can be made from
: other numbers, e.g. 131072 is 256 times 512.  It should have been 512!

: The image is fine, I can view it on PaintBrush for windows say.
: Also, if I strip this header of 'huge' numbers and replace it with the
: numbers 512 ,512, 24, 1 etc then when I read it in again I do get the correct
: numbers, 512, 512 ,24, 1 etc.  But then, of course? , PaintBrush cannot read
: in the image. Obviously the numbers look 'funny' to IT !
[...snip...]

What you have discovered is the little endian vs. big endian problem.
You can read about it in Ada95-LRM:13.5.3. I'm not sure if gnat supports
specifying the bit_order attribute or not, but there are simple solutions
to fix it. One way to do it would be to define a 16 bit unsigned integer
and use 'A := shift_left(A,8)+shift_right(A,8);' (see LRM:B.2). I guess
somebody can tell you the best way to do it (if it isn't the above
solution).
--
+-------------------------+-------------------------------------------+
| Tore B. Joergensen      | e-mail : tore@lis.pitt.edu                |
| Centre Court Villa      | web    : http://www.pitt.edu/~tojst1      |
| 5535 Centre Avenue # 6  |                                           |
| Pgh, PA 15232, USA      | Norwegian MSIS-student at Univ. of Pgh.   |
+-------------------------+-------------------------------------------+