Re: Does Ada support endiannes?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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.
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?
(:-))

> 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).

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.

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.

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.

>      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?

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

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de