Re: Does Ada support endiannes?

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

On Tue, 27 Dec 2011 11:38:32 +0100, Georg Bauhaus wrote:

> On 26.12.11 11:47, Dmitry A. Kazakov wrote:
> 
>> Your code uses obscure assignments to some fields of some record type,
> 
> Or, as one might say, the expression
> 
>  256 * Incoming.Byte_2 + Byte_1
> 
> is an obscure arithmetical formula involving the magic number 256.

   Data (Index) * 2**8 + Data (Index + 1)

> It takes careful study by someone with mathematical training and also
> requires knowledge of language fine print and data representation or
> else 256 is not meaningful, but obscure!

You need mathematical training in order to understand how numbers are
encoded. Representation clauses require much *additional* understanding on
top of that. Difficulties people keep on having with understanding and
proper usage of the clauses reflect this simple fact.

> So, regarding obscurity, the formula would at first show little advantage.
> Neither will it be more readable in this sense.

It is. This is the way these things are defined in first place. E.g.

   http://en.wikipedia.org/wiki/Two_complement

There is simply no other way. The only thing you can do with a number is to
use numeric operations. Anything else is on top of that. Remember that
binary representation of a number is an encoding, itself defined through
mathematical operations.

>> 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?
> 
> Arguably, a chain code might not what a regular programmer would see
> as something to which a record representation clause will apply as a whole.

Regular programmer does not bother about encoding anyway. But if someone
have to, my advise is: don't waste your time on understanding
representation clauses. They won't help you. Beyond trivial cases, if you
are not a language lawyer, you will never understand why that mess works or
does not work.

> What will the concrete data type for the above chain code look like,

An integer number

> as a whole, if it is not a list or array of some sort and if, for example,
> a chain code is being used precisely because there is a lot more to link
> than can be represented in what physically corresponds to
>   range 0 .. 2**System.Word_Size?

That was another point against representation clauses: they fall short when
it comes to validity checks. The peers of the protocol like above would
impose certain implementation-specific limits on the number range. Upon
decoding (using arithmetic operations), the program would necessarily get
Constraint_Error when the limit is exceeded, and reroute to Protocol_Error.
It is a very simple and effective method handling protocols in general.

> It seems there is value in distinguishing an encoding from a representation,
> and establish their relationship.

(Ah, you know my weakness of giving definitions. (:-))

OK, here it one:

[Machine] representation is an encoding with the alphabet based on the
values of a machine type.

P.S. A not yet mentioned argument against representation clauses is their
unfriendliness to correctness proof and testing (you would likely need a
full coverage test).

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