Re: AI12-0218: What is the portable representation clause for processing IETF packets on little-endian machines?

["Randy Brukardt" <randy@rrsoftware.com>]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:c3a4f872-7e24-4d66-a425-776a1aa063f5@googlegroups.com...
On Thursday, May 10, 2018 at 5:40:49 PM UTC-5, Randy Brukardt wrote:
>> . If you just implement it in the front-end using code
>> equivalent to unchecked_conversions, you're forcing all of the operations
>> into memory
>
>Wait, what is the actual extant-in-reality use-case for byte-swapping 
>between
>registers (within the same processor!) of (supposedly-)heterogenous 
>endianness?
>(Not even the PDP-11's mixed endianness did that!)  Does any processor 
>exhibit
>such odd endianness within its own processor('s registers)?  Methinks this 
>is pure
>bicycle-shedding without any basis in reality.

You'd need that to implement AI12-0218-1, or a complete replacement of the 
existing code for handling representation clauses. For Janus/Ada, at least, 
we read the memory into a register, then do various masking an shifting 
operations. One would want to do byte-swapping the same way.

I don't know of any way on the x86 processor of reading a byte-swapped 
32-bit integer into a register so it can be used. If you don't do the byte 
swapping in a register after reading, you would have to do it by doing a-la 
Unchecked_Conversion, copying each byte from one memory location to another 
temporary location in the reverse order, *then* reading the now-swapped 
value into a register. That would be extremely expensive in Janus/Ada, since 
we don't have any way to allocate temporary memory in many places where such 
reads would occur (the fall back would be heap allocation/deallocation!).

Besides, the x86 has instructions like Xchg AL, AH which do byte swapping in 
registers. One would rather use those rather than do extra memory 
operations.

Thus, I conclude that back-end changes would be needed.

I don't know the situation on other processors vis-a-vis byte swapping, but 
one can always generate the best possible code if the back-end is aware of 
the need. Emulating it in the front-end can often end up sub-optimal.

>> don't allow any hardware support to get used.
>
>Hmmm, that one is somewhat more compelling if the processor has 
>byte-swapping instructions.

If such instructions aren't available, you have either the choice of 
Unchecked_Conversion (memory to memory swapping, followed by usual reading) 
or doing it in a pair of registers with shifting/masking. I'd rather do the 
latter, since the easiest way to speed up a program is to reduce the amount 
of memory use. (The correlary is the reverse is also true. :-)

                            Randy.