RE: Standard Ada Preprocessor

RE: Standard Ada Preprocessor

[Lionel.DRAGHI]

| -----Message d'origine-----
| De: Robert I. Eachus [mailto:rieachus@comcast.net]
...
| 
| Somebody wrote an article (for Ada Letters I think) on how to write 
| representation specifications that are legal (and identical!) for 
| bigendian and little endian hardware.  Anyone remember it?

Could be :
 
- Endian-Safe Record Representation Clauses for Ada programs
  Mike Mardis, Ada Letters, December 99.

or 
- Endian-Independent Record Representation Clauses
  Norman H, Cohen, Ada Letters Jan/Feb 94

-- 
lionel Draghi

Re: Standard Ada Preprocessor

[Robert I. Eachus]

Lionel.DRAGHI@fr.thalesgroup.com wrote:

> Could be :
>  
> - Endian-Safe Record Representation Clauses for Ada programs
>   Mike Mardis, Ada Letters, December 99.
> 
> or 
> - Endian-Independent Record Representation Clauses
>   Norman H, Cohen, Ada Letters Jan/Feb 94

Thanks!  It happened to be Norm's paper that I remembered.  But I guess 
it must be time to publish such a paper again. ;-)

Actually, I assume that Mike's paper is an update based on Ada 95, and 
that if there are any changes in this area in Ada 0Y, that a new paper 
will be needed.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Endian-Independent Rep Clauses (was: Standard Ada Preprocessor)

[Jeffrey Carter]

Robert I. Eachus wrote:

> Lionel.DRAGHI@fr.thalesgroup.com wrote:
> 
>> Could be :
>>  
>> - Endian-Safe Record Representation Clauses for Ada programs
>>   Mike Mardis, Ada Letters, December 99.
>>
>> or - Endian-Independent Record Representation Clauses
>>   Norman H, Cohen, Ada Letters Jan/Feb 94
> 
> 
> Thanks!  It happened to be Norm's paper that I remembered.  But I guess 
> it must be time to publish such a paper again. ;-)
> 
> Actually, I assume that Mike's paper is an update based on Ada 95, and 
> that if there are any changes in this area in Ada 0Y, that a new paper 
> will be needed.
> 

IIRC, it addresses the fact that Default_Bit_Order is static, thanks to 
an AI, and uses static universal math based on Boolean'Pos 
(Default_Bit_Order = <one_of_the_choices>) to calculate bit positions. 
I've done this kind of thing; it requires long expressions for bit 
numbers, but works fine.

-- 
Jeff Carter
"I'm a lumberjack and I'm OK."
Monty Python's Flying Circus
54

Re: Endian-Independent Rep Clauses

[Robert I. Eachus]

Jeffrey Carter wrote:

> IIRC, it addresses the fact that Default_Bit_Order is static, thanks to 
> an AI, and uses static universal math based on Boolean'Pos 
> (Default_Bit_Order = <one_of_the_choices>) to calculate bit positions. 
> I've done this kind of thing; it requires long expressions for bit 
> numbers, but works fine.

Not really, just declare:

Bits: constant := System.Bit_Order'Pos(System.Default_Bit_Order);

then go on from there.
-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Endian-Independent Rep Clauses

[Stephen Leake]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> Jeffrey Carter wrote:
> 
> > IIRC, it addresses the fact that Default_Bit_Order is static, thanks
> > to an AI, and uses static universal math based on Boolean'Pos
> > (Default_Bit_Order = <one_of_the_choices>) to calculate bit
> > positions. I've done this kind of thing; it requires long
> > expressions for bit numbers, but works fine.
> 
> Not really, just declare:
> 
> Bits: constant := System.Bit_Order'Pos(System.Default_Bit_Order);
> 
> then go on from there.

Here's a real-life example:

package SAL.Endianness is
   Bit_Order      : constant := 1; -- 1 or -1
   High_Bit_First : constant := 0; -- 0 or 1
   Low_Bit_First  : constant := 1; -- opposite of High_Bit_First

   --  Use one of these, corresponding to the natural size of the
   --  record you are laying out.
   LSBit_8  : constant := High_Bit_First *  7;
   LSBit_16 : constant := High_Bit_First * 15;
   LSBit_24 : constant := High_Bit_First * 23;
   LSBit_32 : constant := High_Bit_First * 31;
   LSBit_56 : constant := High_Bit_First * 55;
end SAL.Endianness;

with SAL.Endianness; use SAL.Endianness;
package body DA.Digital is

   type Analog_Collection_Mode_Type is record
      Spare_1   : Interfaces_More.Unsigned_30;
      Data      : Interfaces_More.Unsigned_2;
   end record;

   for Analog_Collection_Mode_Type use record
      Spare_1 at 0 range
        Low_Bit_First  * (LSBit_32 + Bit_Order *  2) + High_Bit_First * (LSBit_32 + Bit_Order * 31) ..
        High_Bit_First * (LSBit_32 + Bit_Order *  2) + Low_Bit_First  * (LSBit_32 + Bit_Order * 31);

      Data at 0 range
         Low_Bit_First  * (LSBit_32 + Bit_Order *  0) + High_Bit_First * (LSBit_32 + Bit_Order *  1) ..
         High_Bit_First * (LSBit_32 + Bit_Order *  0) + Low_Bit_First  * (LSBit_32 + Bit_Order *  1);

   end record;
   for Analog_Collection_Mode_Type'Size use 32;

    ...
end DA.Digital;

There is probably a way to improve the SAL.Endianness package, so I
don't need more than one. I was unable to find a smaller expression
for the rep clauses.

-- 
-- Stephe

Re: Endian-Independent Rep Clauses

[Robert I. Eachus]

Stephen Leake wrote:
...
> There is probably a way to improve the SAL.Endianness package, so I
> don't need more than one. I was unable to find a smaller expression
> for the rep clauses.

You can use the method I recommended for defining the contents of 
SAL.Endianness in a manner that derives it all from 
System.Default_Bit_Order.  Then it is really worth defining some 
additional constants there that make it easier to define some common 
fields.  i.e.

Byte1_First: constant := ....
Byte1_Last constant := ...

Then you can layout things using those constants.  The way I do it is to 
put all the cruft into one package spec, then when I need a bit position 
defined that isn't in there, I add it.  It could grow like Topsy, but I 
found that mostly I needed about a dozen values.  (But it is worth 
noting that I had two sets, one set that was right for String layouts 
and another for numbers.)

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Endian-Independent Rep Clauses

[Jeffrey Carter]

Stephen Leake wrote:
> 
> Here's a real-life example:
> 
> package SAL.Endianness is
>    Bit_Order      : constant := 1; -- 1 or -1
>    High_Bit_First : constant := 0; -- 0 or 1
>    Low_Bit_First  : constant := 1; -- opposite of High_Bit_First

Derive these from System.Default_Bit_Order.

I generally like to predefine a collection of useful bit numbers as well.

-- 
Jeff Carter
"Beyond 100,000 lines of code you
should probably be coding in Ada."
P. J. Plauger
26

Re: Endian-Independent Rep Clauses

[Stephen Leake]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> Stephen Leake wrote:
> ...
> > There is probably a way to improve the SAL.Endianness package, so I
> > don't need more than one. I was unable to find a smaller expression
> > for the rep clauses.
> 
> You can use the method I recommended for defining the contents of
> SAL.Endianness in a manner that derives it all from
> System.Default_Bit_Order.  

Yes, others have suggested that. I haven't found it to be worth the
time, yet.

> Then it is really worth defining some additional constants there
> that make it easier to define some common fields. i.e.
> 
> Byte1_First: constant := ....
> Byte1_Last constant := ...

Hmm. I guess Byte1_First is 8 for little endian, and Byte1_Last is 15?
But it depends on the size of the whole record for big endian, so it
can't be a constant. That's what LSBit_32 etc is for. I have LSBit_56
because I encountered a 56 bit record once.

I guess I could have Byte1_of_4_first, Byte1_of_5_first, etc.

> Then you can layout things using those constants. The way I do it is
> to put all the cruft into one package spec, then when I need a bit
> position defined that isn't in there, I add it. It could grow like
> Topsy, but I found that mostly I needed about a dozen values. (But
> it is worth noting that I had two sets, one set that was right for
> String layouts and another for numbers.)

Could you post an example from real code? Or perhaps for the record I
posted? All I get from your message is "it's possible to do better";
if I could figure it out from that, I'd have done it already :).

-- 
-- Stephe

Re: Endian-Independent Rep Clauses

[Stephen Leake]

Jeffrey Carter <spam@spam.com> writes:

> Stephen Leake wrote:
> > Here's a real-life example:
> > package SAL.Endianness is
> >    Bit_Order      : constant := 1; -- 1 or -1
> >    High_Bit_First : constant := 0; -- 0 or 1
> >    Low_Bit_First  : constant := 1; -- opposite of High_Bit_First
> 
> Derive these from System.Default_Bit_Order.

Someday I'll do that :).

> I generally like to predefine a collection of useful bit numbers as
> well.

Hmm. In the systems I've built, I haven't noticed that any one bit
number occurs more often than another; are you saying you have?

Can you post a real example of your style of rep clause? That might
help me understand your approach better.

-- 
-- Stephe