From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: AI12-0218: What is the portable representation clause for processing IETF packets on little-endian machines? Date: Fri, 11 May 2018 17:00:54 -0500 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Fri, 11 May 2018 22:00:55 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="28975"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:52298 Date: 2018-05-11T17:00:54-05:00 List-Id: "Dan'l Miller" 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.