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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.176.69.147 with SMTP id u19mr9152441uau.10.1472681875292; Wed, 31 Aug 2016 15:17:55 -0700 (PDT) X-Received: by 10.157.29.252 with SMTP id w57mr1321546otw.16.1472681875240; Wed, 31 Aug 2016 15:17:55 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!border2.nntp.ams1.giganews.com!nntp.giganews.com!c52no12288208qte.1!news-out.google.com!n186ni1564ith.0!nntp.google.com!e124no184618ith.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 31 Aug 2016 15:17:54 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=213.108.152.51; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S NNTP-Posting-Host: 213.108.152.51 References: <7595494c-3398-4fd9-ab4b-80a79383ae33@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <315a724f-0b77-47fd-9448-369e4670fc99@googlegroups.com> Subject: Re: for X'Address use - and Volatile From: Maciej Sobczak Injection-Date: Wed, 31 Aug 2016 22:17:55 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:31666 Date: 2016-08-31T15:17:54-07:00 List-Id: > Ada does not now, nor ever has, officially supported overlays. Such code= =20 > might work on a particular implementation, but it's not portable (even to= =20 > another version of the same compiler). [...] Thanks for the explanation, which hits some interesting point. It is true that such code goes outside of the standard and relies on the pr= ogrammer's knowledge about some particular implementation. This is similar = in nature to many obscure hacks in C, too. It might work, because we *know*= that it does - perhaps we have even verified it by whatever means. But onc= e we rely on the details of some particular implementation, it does not mak= e much sense to ask whether something is superfluous or not from the standa= rd's perspective - we are already outside of the standard, so standard is n= o longer an authority. Oops. :-) > Indeed, address clauses ought to be avoided for all but their intended=20 > purpose (mapping to hardware registers); I'd disagree here. Mapping to hardware registers (or mapping to memory regi= ons in general) should be performed at the linker and loader level, which h= ave much better tools for handling such tasks (also, at that level, there m= ight be other languages involved, which really means that a common denomina= tor is needed instead of pseudo-high-level solutions). I understand that st= andard authors did not presume the existence of the linker as a separate en= tity and therefore tried to solve everything in the language, but the whole= idea of "mapping to hardware registers" is already target-specific and can= not be addressed (pun intended) in abstract terms, which is how the languag= e is defined in the standard. In other words, for hardware registers I woul= d use a pragma Imported objects and allocate them in the linker script inst= ead. So, as far as I'm concerned, the whole "for X'Address use" idiom is us= eless. And last by not least - I don't like to tie the source code to the h= ardware this way. But I have a code that resembles a pile of C hacks and now the only thing t= hat leads me in its analysis is "if it works then it's good", because the s= tandard was already thrown out the window. Sigh. --=20 Maciej Sobczak * http://www.inspirel.com