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: for X'Address use - and Volatile Date: Wed, 31 Aug 2016 20:22:49 -0500 Organization: JSA Research & Innovation Message-ID: References: <7595494c-3398-4fd9-ab4b-80a79383ae33@googlegroups.com> <315a724f-0b77-47fd-9448-369e4670fc99@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1472692958 11101 24.196.82.226 (1 Sep 2016 01:22:38 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 1 Sep 2016 01:22:38 +0000 (UTC) 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.6157 Xref: news.eternal-september.org comp.lang.ada:31668 Date: 2016-08-31T20:22:49-05:00 List-Id: "Maciej Sobczak" wrote in message news:315a724f-0b77-47fd-9448-369e4670fc99@googlegroups.com... ... >> Indeed, address clauses ought to be avoided for all but their intended >> purpose (mapping to hardware registers); > >I'd disagree here. Mapping to hardware registers (or mapping to memory >regions in general) >should be performed at the linker and loader level, which have much better >tools for handling >such tasks... That's not my experience. Getting a linker to do anything at all is a royal pain, we avoided it as much as possible (most versions of Janus/Ada can directly produce executables if no foreign code is needed, not the Windows version, unfortunately). And by putting essentially everything in the the Ada code, it becomes portable to other Ada compilers. (Gnatmake might be specific to GNAT, but every Ada compiler has something like it, so compiling Ada source is easy with other Ada compilers. Problems arise mainly when one reaches the boundary of what Ada can do.) There's a problem in that version control systems mostly fail to deal properly with multiple versions of a file (they should be kept in sync mostly automatically), but that's definitely not Ada-related (every language struggles with that problem more-or-less). > ... So, as far as I'm concerned, the whole "for X'Address use" idiom is > useless. I agree with this, but mainly because I rarely do hardware these days. :-) > And last by not least - I don't like to tie the source code to the > hardware this way. I'd rather tie Ada-standard source code (properly encapsulated, of course) to hardware than anything specific to a single implementation. There has to be a good reason to avoid portability, and there isn't one here. > But I have a code that resembles a pile of C hacks and now the only thing > that > leads me in its analysis is "if it works then it's good", because the > standard was > already thrown out the window. Sigh. Well, you made that choice. It doesn't have to be that way. (If you're an implementer, the situation is different, but one hopes that most programmers don't need to stick their fingers into those light sockets.) Randy.