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!newsfeed.xs3.de!io.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: Portable memory barrier? Date: Wed, 10 May 2017 20:02:20 -0500 Organization: JSA Research & Innovation Message-ID: References: <0fc56bf7-1cfa-4776-9c47-a573db315c5f@googlegroups.com> <7b0c08eb-be62-4d14-ae99-cad038ad0a62@googlegroups.com> <077e7f6a-5a7b-4b88-a16f-7672aec18a17@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: franka.jacob-sparre.dk 1494464541 2881 24.196.82.226 (11 May 2017 01:02:21 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 11 May 2017 01:02:21 +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:46758 Date: 2017-05-10T20:02:20-05:00 List-Id: "Robert Eachus" wrote in message news:df31d3f8-636f-4702-affe-d5a0aa0c898a@googlegroups.com... On Tuesday, May 9, 2017 at 3:57:50 PM UTC-4, Randy Brukardt wrote: > "Robert Eachus" wrote in message > news:077e7f6a-5a7b-4b88-a16f-7672aec18a17@googlegroups.com... > ... >> >The compiler will play some games, and certainly will leave Write_Index >> >in >> >a register if possible. >> >> It better not is Write_Index is Atomic. > >First, if FIFO has Atomic_Components, then it is not possible. >Atomic_Components would be >overkill, but I haven't seen those declarations here. If FIFO has just >Volatile_Components (or >no attribute) then this is possible. But what is "this"? ???? Write_Index needs to be atomic in order for the OP's algorithm to work. Atomic objects fall under C.6(20/5) -- all reads and updates are included in the external effect of the program. Optimizing them out (in any way) is wrong (excepting of course a true as-if optimization, but that doesn't make any sense in this case). In particular, saving the value in a register is useless, because you still have to read the object again at the next reference. >Sloppy wording, I should have said "keep a copy of Write_Index". The write >to Write_Index >will occur to cache on modern systems where the whole system is >cache-coherent. But that is >a detail. What I was specifically referring to was that there are two >subexpressions >Write_Index+1. As far as I can tell, if there are no synchronization >points between them, the >(overall system including) the compiler can do one read of Write_Index, >then evaluate the >expression once--or twice. Definitely not (again assuming Write_Index is atomic). One has to make the reads of memory for an atomic object, saving copies is wrong. And there is no real value to eliminating the +1 -- in-register operations are essentially free on modern architechtures. Since the rest of your discussion is based on an incorrect premise, I'm going to skip it. (Other than to say, if you need the fastest possible code, don't make anything volatile or atomic! They're for synchronization, which necessarily is going to be slower than the usual code, since it has to be predictable.) ... >> Only the compiler vendor need worry about this level of discussion. >> Honestly, I doubt anyone else is qualified. (I'm not, and I AM a compiler >> vendor... ;-) > >I used to be a compiler writer, on at least three Ada compilers, but the >deep level >understanding of what is going on comes from my work on radar systems. >There >access times in microseconds are important, and sometimes in nanoseconds. >(I think >the worst real-time requirement I ever saw was for 200 nanoseconds. Ouch!) I know that (and so am I), but my complaint was that the discussion isn't helpful to the OPs question (which is how to do this in hopefully portable Ada); it's the compiler's job to get this right and one hopes that the only time anyone needs to worry about this is if they have a bug that they think is caused by the compiler doing this wrong. (And this is when AdaCore support contracts pay for themselves, because you can dump the problem on them and let them figure it out. And it's the sort of problem that makes those contracts so expensive, because it is HARD work!!) Randy.