Re: Using representation clauses in networking software

[Florian Weimer <fw@deneb.enyo.de>]

* Dmitry A. Kazakov:

> On Sun, 15 Aug 2010 16:44:33 +0200, Florian Weimer wrote:
>
>> * Dmitry A. Kazakov:
>> 
>>> On Sun, 15 Aug 2010 15:44:34 +0200, Yannick Duch�ne (Hibou57) wrote:
>>>
>>> (I agree with what you wrote. I am programming a lot of communication
>>> stuff, but never used representation clauses to handle endianness.)
>> 
>> This is not surprising because the current representation clauses
>> cannot handle it.
>
> What for, if there are better ways to handle it? Representation layout
> clause was invented for handling something in place. It is no more actual,
> because reading out/writing in with an appropriate recoding is cleaner and
> possibly cheaper on modern hardware.

It's quite difficult to come up with the best approach to
deserialization for a particular architecture.  There are some pretty
common CPUs that handle unaligned loads quite well, so it's unclear
that the load-a-byte-at-a-time-and-shift approach is a win.  Same for
serialization.

>> I wonder if there has been any attempt to enhance representation
>> clauses so that they are useful in this context.
>
> To handle all possible cases of mixed-endian? To handle non-2's complement
> integers? IEEE, IBM, DEC float layouts? Layouts of Character like EBCDIC,
> KOI-7/8 etc? It would be a mammoth task to accomplish. What is the gain?

So why were representation clauses added to Ada in the first place?
Would it make sense to deprecate them?

(Endian issues arise even when controlling devices because most PCI
devices you can plug into a big-endian box expect little endian
memory-mapped I/O.)