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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,d778a4f52acd9d43 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.191.41 with SMTP id gv9mr23878696pbc.5.1325137325463; Wed, 28 Dec 2011 21:42:05 -0800 (PST) MIME-Version: 1.0 Path: lh20ni76312pbb.0!nntp.google.com!news1.google.com!goblin2!goblin.stu.neva.ru!feeder2.cambriumusenet.nl!feed.tweaknews.nl!62.179.104.142.MISMATCH!amsnews11.chello.com!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!jacob-sparre.dk!ada-dk.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Representation clauses for base-64 encoding Date: Wed, 28 Dec 2011 23:41:57 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <4ef31672$0$6574$9b4e6d93@newsspool3.arcor-online.net> <9lgls6FticU1@mid.individual.net> <9m0433FjokU1@mid.individual.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1325137322 2549 69.95.181.76 (29 Dec 2011 05:42:02 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 29 Dec 2011 05:42:02 +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 Date: 2011-12-28T23:41:57-06:00 List-Id: "Niklas Holsti" wrote in message news:9m0433FjokU1@mid.individual.net... > On 11-12-23 03:42 , Randy Brukardt wrote: >> "Niklas Holsti" wrote in message >> news:9lgls6FticU1@mid.individual.net... >> ... >>>> http://www.adacore.com/2008/03/03/gem-27/ >>> >>> I am surprised and disappointed that there is *no* mention of >>> portability >>> problems in that "gem". This is marketing hype for GNAT, not sound >>> programming advice. >> >> There is no portability problem in common use. > > Depends on what you consider common. The gem even claims that its > representation clause makes "Ada" use a biased 7-bit representation for an > Integer component with range 100..227. RM chapter 13 only recommends that > compilers should support unbiased representations. > > Which Ada compilers, other than GNAT, can use biased representations? Ah, I missed that. I don't know of any other Ada compilers that support biased representations. ... > Natasha's 24-bit-record code works only if the Ada implementation (a) > supports chapter 13 as recommended and (b) has a machine scalar of at > least 24 bits. No, not true. Machine scalars only come into play if you need to use the non-native bit order, and that isn't needed here. Once you have to work with the non-native bit order, things get messy. But that is rarely needed. > We know that some Ada programs run on the 16-bit TI MSP430. Will the > 24-bit record code work there? Ok, MSP430 Ada programs are uncommon, but > perhaps we want to make them more common. Sure, it will work there, so long as you don't try to mess with the non-native bit order. > Natasha's code that uses (packed) arrays with Component_Sizes of 6 and 8 > bits has more complex portability questions. Of course it also requires > support for chapter 13, but I think it needs more than that. It depends on > the indexing order and the word size. I don't find anything in chapter 13 > or elsewhere in the RM that even requires the indexing order to be the > same for different array types, although this is of course very likely to > be the case. Worrying about indexing order is just plain silly. As Bob points out, *nothing* is really required by a standard, you have to trust implementers to do reasonable things. >> The problem occurs when you need to process big-endian data on a >> little-endian machine (or vice versa). That is not that common of a >> need -- > > The problem occurs when an application inputs or outputs binary data, and > the application should be coded in a portable way. I can't believe that > this is uncommon. Only if the binary data is in the non-native bit order. If the binary data is in the native bit order, there is nothing that special that needs to be done. And it doesn't matter which bit order that is. >> Most code does not care which bits are which bits in the word -- like >> this >> encoding code -- they just need a consistent representation. That is, it >> doesn't matter where bit 0 is, so long as it is the same in every item >> that >> is processed. > > True for internal data, false for inputs and outputs. Not really. The vast majority of inputs and outputs are in text form (as in the encoding example). Most of the rest are just a pure stream of bytes. And the interesting thing with a stream of bytes is that you get identical behavior for both bit orders -- because the bit order and byte order are tied together. The problem comes when you try to use the non-native bit and byte order on a machine. For instance, in the encoding example, all of the messy manipulation occurs completely inside the application: the input is a stream of bytes and the output is a stream of characters -- neither are subject to any byte order issues themselves. That being the case, which bytes go where (internally) turns out to be irrelevant, because the native order will have the right effect either way. It took me a long time to grasp this; I only figured it out after struggling for a long time with our old 68000 code generator (which is big-endian, of course). Once I got the code selection right, nothing much needed to be changed. I understand when others don't see this; it's easy to think too much in terms of the exact bits involved, but those matter less than it may seem. Randy.