Re: Endian-Independent Rep Clauses

[Stephen Leake <stephen_leake@acm.org>]

"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