Re: Does Ada support endiannes?

[csampson@inetworld.net (Charles H. Sampson)]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:

> On Thu, 15 Dec 2011 01:14:15 -0800, Charles H. Sampson wrote:
> 
> > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> > 
> >> I think the problem here is not the volume of the code, but an untyped
> >> nature of it.
> > 
> >      My code gets "typed" as soon as possible, as soon as I can
> > recognize what its type is supposed to be.  The reason I wrote _typed_
> > in quotes is that a stream of bits, where I start, is typed:
> > 
> >    type Bit is range 0 .. 1;
> >    for Bit'Size use 1;
> >    type Bit_Stream is array (Positive range <>) of Bit;
> >    pragma Pack (Bit_Stream);
> 
> In order to make this working with representation clause you have to get
> bits out of this stream and store them into a properly aligned array of
> Storage_Unit. Doing so, you will have to take into account native storage
> unit bit endianness, which may differ from the endiannes of the protocol.
> Furthermore, since almost all protocols are octet-oriented rather than
> bit-oriented, you will need to decode the protocol's stream of octets into
> bits and then recode that into an array of storage units to apply a
> representation clause on that.

     He's baaaaack!  Sorry to leave such a time gap in this thread but I
had to find time during this busy season to commune with the LRM at bit.

> 
> A rationale for such an exercise is beyond me, but certainly this is not
> what anybody could call "simple" or "readable."
> 
> >      Sometime the time between the IO and the conversion is longer than
> > you might hope, at least on the input side.  Referring again to the last
> > system I worked on, we often had to read part of the input to determine
> > the length of the incoming bit string, then read the rest in, and then
> > begin the checking to determine exactly what we had.
> 
> Yes, and this is yet another argument against representation clauses which
> tend to convert things as a whole. The problem is that protocols are using
> finer grained elements, that data might be corrupted, not ready as a whole
> etc. Using representation clauses you will have problems with validating
> data after conversion. You must ensure that no invalid bit pattern may
> become a valid value after re-interpretation using a representation clause.
> When using arithmetic of octets this is done in the course of conversion,
> almost automatically. With representation clauses you would likely have to
> add some extra checks before storing the data and after the
> re-interpretation.

     I'm not clear on what you mean by "representation clauses ... tend
to convert things as a whole".  Representation clauses don't convert
anything.  They just specify how the bits are laid out in memory.  It
doesn't matter how those bits got there.  In the present case, probably
a low-level routine was called telling it to place the incoming packet
at a certain place in memory.  It's only after the bits are in the
proper place that any conversion takes place.  For example, to change
the endianess of a two-byte word, I might write something like

   Internal_Small_Word := 256 * Incoming.Byte_2 + Byte_1;

It's more than likely that I would use a representation clause for
Internal_Small_Word also and just do two assignments:

   Internal_Small_Word.Byte_1 := Incoming.Byte_2;
   Internal_Small_Word.Byte_2 := Incoming.Byte_1;

It won't surprise you when I say that I think the latter is much clearer
as to intent and meaning than any arithmetic manipulating, including my
former example.

     Data corruption is handled by whatever mechanism is in the data
packets to guard against corruption.  In my experience that was usually
a pretty simple-minded checksum.  Whenever a corrupted packet was
detected, all of its data were thrown away.

    As to checks of incoming data before storing, I usually let Ada do
that for me by properly defining the target data type.  I remember
having to occasionally use 'Valid but I don't remember exactly when.  I
think it had something to do with holey enumerations.

> >> As a by-product you get a highly portable code as Gautier pointed out in
> >> another response.
> > 
> >      I don't understand this claim of highly portable code without using
> > a rep spec.
> 
> The semantics of a representation clause depends on the native machine bit
> and storage unit endianness, the size of the storage unit, alignment
> constraints. The semantics of arithmetic operations and shifts is fully
> machine-independent.

     You've given rep clauses more semantics than the LRM.  They simply
specify how bits are laid out.  I (and the people I lead) avoid storage
unit issues by writing component clauses of the form

   for Component use at 0 range ...

That is, the layout is specified relative to the beginning of the
record.  Comments usually tie this to the document that specified the
data layout.

     I could also get around native machine endianess by specifying the
bit order; for some reason I didn't.

     The down side of this form of component clause is that, without the
comments, it is a little obscure.  I decided to make that tradeoff in
order to get better native machine transportability.

> The rule of thumb: representation clauses shall be used exclusively for the
> machine hardware. This is the only legitimate case for them.

     Isn't that what I've been advocating?  Using representation clauses
when the hardware of one machine doesn't match the hardware of another?
I hope nothing I've written was interpreted as meaning you should
sprinkle rep clauses around like holy water.  I religiously avoid using
them except when absolutely necessary.  (Your meaning of "absolutely
necessary" might differ from mine.)

                        Charlie
-- 
Nobody in this country got rich on his own.  You built a factory--good.
But you moved your goods on roads we all paid for.  You hired workers we
all paid to educate. So keep a big hunk of the money from your factory.
But take a hunk and pay it forward.  Elizabeth Warren (paraphrased)