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!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!reality.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Byte Swapping Date: Fri, 2 Dec 2016 13:28:04 -0600 Organization: JSA Research & Innovation Message-ID: References: NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1480706826 13598 24.196.82.226 (2 Dec 2016 19:27:06 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 2 Dec 2016 19:27:06 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:32559 Date: 2016-12-02T13:28:04-06:00 List-Id: "Jeffrey R. Carter" wrote in message news:o1s73q$qmg$1@dont-email.me... > Recently on Ada-Comment there was a discussion of a GNAT aspect that > changes the byte order of scalars. Brukardt said, "In the past, we have > not be willing to require compilers to be able to generate byte swapping > code." However, I think the standard has required compilers to generate > byte-swapping code since Ada 83. > > On a little-endian, twos-complement, byte-addressable machine, such as > x86, we could say > > Byte_Size : constant := 8; > Word_Size : constant := 2 * Byte_Size; > > type Byte is range -(2 ** (Byte_Size - 1) ) .. 2 ** (Byte_Size - 1) - 1; > for Byte'Size use Byte_Size; > type Word is range -(2 ** (Word_Size - 1) ) .. 2 ** (Word_Size - 1) - 1; > for Word'Size use Word_Size; > -- Signed types for Ada-83 compatibility > > type Unswapped_Bytes is record > MSB : Byte; > LSB : Byte; > end record; > > for Unswapped_Bytes use record > MSB at 1 range 0 .. 7; > LSB at 0 range 0 .. 7; > end record; > for Unswapped_Bytes'Size use Word_Size; > -- Default LE byte order: LSB at offset 0, MSB at offset 1 > > type Swapped_Bytes is new Unswapped_Bytes; > > for Swapped_Bytes use record > MSB at 0 range 0 .. 7; > LSB at 1 range 0 .. 7; > end record; > for Swapped_Bytes'Size use Word_Size; > -- BE byte order: MSB at offset 0, LSB at offset 1 > > IIUC, type conversion between these two record types performs byte > swapping. So, with > > function To_Unswapped is new Unchecked_Conversion > (Source => Word, Target => Unswapped_Bytes); > function To_Word is new Unchecked_Conversion > (Source => Swapped_Bytes, Target => Word); > > W : Word; > > To_Word (Swapped_Bytes (To_Unswapped (W) ) ) > > produces a Word with the bytes of W swapped. Barring any errors I've > injected, this should be valid Ada 83 and all later version of the > language. Sure, but that's typcially implemented by doing a component-by-component assignment into a temporary (and the rep. clause is illegal for any by-reference type). That code is very slow, but that's OK because type conversions like this are rare in the language and occur rarely even when they are used. The suggested aspect would require the compiler to be able to generate byte swapping code for a component reference. While that wouldn't be commonly used, when it is used, the code would have to be as efficient as possible as it would probably occur a lot. So the degree of effort is quite different. To put it another way, a value type conversion "feels" expensive (one tries to avoid them), while a component access "feels" cheap (one does not try to avoid them), and the generated code needs to reflect that. This is the crux of my (mild) objection to this idea: it makes component access for some record types quite expensive, and I doubt that most users would want to pay that cost regularly. The proper way to deal with data in the wrong byte-sex is to swap it as soon as possible and then process it in the native byte-sex. That means that the programmer has to be aware of it; trying to make a truly machine-independent format is somewhat of a mistake, as the code would be very slow on some targets. Don't see how that helps anything. Randy.