Re: Does Ada support endiannes?

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

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

> On Sun, 25 Dec 2011 13:42:45 -0800, Charles H. Sampson wrote:
> 
> >      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.
> 
> But you want to use them for conversions. You somehow put raw data there
> and then reinterpret that as an integral ADT object, usually an integer.

     I don't reinterpret the raw data,  Based on some knowledge of the
data the representation clause defines its interpretation.  Until we get
to that point, the data are, for me, just a string of bits.  Very seldom
is that interpretation an integer; most often it is a somewhat complex
structure of non-homogenous components, the very definition of a record.

> What about a task object? Consider an agent-based application using some
> protocol to transport agents (tasks) over the network. Would you
> reconstruct an agent from bits and bytes using a representation clause?
> (:-))

     I have no concept of a task object being transported over a
network.  The closest I can come is an indicator (integer or enumeration
type) specifying a task object on the receiving machine to be used.  For
anything else, I'll have to wait until I see one to decide what my
strategy would be.

> > 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.
> 
> No. The first variant follows the mathematical definition of how an integer
> of the range 0 .. 2**16 - 1 is encoded as a sequence of octets (integers
> range 0 .. 2**8 - 1).

     And the second variant shows how to rearrange some of the incoming
bits to get the same value in native machine form.

> 
> Your code uses obscure assignments to some fields of some record type,
> which connection to the mathematical definition of an encoded number is not
> clear to the reader, as well as the correctness of the code, because the
> order of bytes and gaps between them is specified somewhere else by a
> representation clause.

     And your code uses obscure multiplications that are really a
disguised form of shifts.  If you're thinking shifts, why not use a
shift function?

     From a mathematical point of view, your multiplication code is
treating two bytes of the incoming code as digits in a base 256
representation.  For a mathematician, that's clear.  It can be confusing
and surprising to a non-mathematician.

> Note also that all examples you and others have so far provided, go no
> further swapping bytes and trivial bit fields extraction. This is too
> little for real-life applications.

     The subject of this thread had to do with endianess.

> Consider a PT100 WAGO Modbus module. It delivers a WORD (two bytes) in
> so-called Siemens format. 12 MSBs encode the value from -200 to 883 degree
> Celsius represented as 0400..7FF8. Bigger and lesser values are cropped.
> The 4 LSBs bits are the diagnostics bits (curcuit open/close etc). You
> could not handle this using a representation clause in one step. You will
> have first to swap bytes to build a 16 bit integer and use it to obtain the
> temperature masking and shifting. Or, first reorder and extract 12 bits,
> extract 4 bits, check, recode 12 bits into value. In both cases
> arithmetical operations are unavoidable.

     I'm pretty sure I could do it to my satisfaction but I've got too
many questions about your description to actually write any code.  For
example, are 200 and 883 in decimal or hex?  What about endianess?
Doesn't the value 7FF8 preclude using the 4 LSBs as diagnostic bits?

     Regarding "You could not handle this using a representation clause
in one step.", I don't know what "this" refers to.  Even if I did, what
is the importance of "one step"?  Am I correct in assuming that "one
step" means "one statement"?  If so, that's unimportant to a reasonably
good optimizing compiler, which can ofter encode sequences of statement
as though they were one complex statement.

> >      Data corruption is handled by whatever mechanism is in the data
> > packets to guard against corruption.
> 
> As I said, you need something to add, in order to check validity of the
> values obtained from the conversion. X'Valid is no help in the examples
> like above, when values are saturated and/or additional bits or patterns
> are used to indicate validness.
> 
> Another example chain codes. E.g. the following encoding of cardinal
> numbers:
> 
> 0 -> 2#0000_000#
> 1 -> 2#0000_0001#
> ...
> 127 -> 2#0111_1111#
> 128 -> 2#1000_0000# 2#0000_0001#
> 129 -> 2#1000_0001# 2#0000_0001#
> ...
> 4095 -> 2#1111_1111# 2#0111_1111#
> 4096 -> 2#1000_0000# 2#1000_0000# 2#0000_0001# 
> ...
> 
> [Chain codes are used when the upper bound of the transported number is
> unspecified and it is expected that lesser values are more frequent than
> bigger ones. UTF-8, is chain code.]
> 
> Care to write a representation clause for the above?

     No, because they are not of a record type.  Give me some
information about how the chains are laid out in memory and I should be
able to come up with some useful type definitions.
 
> >> 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?
> 
> In that case we are in agreement that they should not be used for handling
> I/O protocols.
> 
> The only useful examples of representation clauses I saw were descriptions
> of machine registers, e.g. the bits of the processor status word, of the
> memory mapping registers etc. IMO, this is the only legitimate use for
> them: systems programming, machine-specific, once in 10 years or never.
> 
> > Using representation clauses
> > when the hardware of one machine doesn't match the hardware of another?
> 
> All sorts of I/O: reading data from a hardware port, from a socket, from
> dual-ported shared memory etc.

     I started to say once before that I think I see the primary
difference between us but I never quite got it out.  To me, data being
input "over a wire" are a sequence of bits and I use record types with
representation clauses as soon as I can to specify the meaning of those
bits.  You seem to see those data as a stream of bytes that contain
integers in the range 0 .. 255 and you specify the meaning by doing
arithmetic manipulations.  I also believe in "programming with data" and
it appears that you don't, or at least you don't to the degree that I
do.   Those are pretty fundamental differences between us from the
get-go so it's not suprising that we end up with quite different looking
code to accomplish the same task.

     If my characterization of your approach is correct, then how you do
you handle a stream of bytes when some of them represent characters?  Do
you use 'Val?  What do you do when some of the bytes, when combined
properly, represent a "signed" integer (i.e. a value that could be
negative)?

                        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)