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.237.35.8 with SMTP id h8mr2962881qtc.67.1494433158440; Wed, 10 May 2017 09:19:18 -0700 (PDT) X-Received: by 10.157.17.23 with SMTP id g23mr148314ote.4.1494433158395; Wed, 10 May 2017 09:19:18 -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!border1.nntp.ams1.giganews.com!nntp.giganews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.am4!peer.am4.highwinds-media.com!peer02.fr7!futter-mich.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!t26no256764qtg.1!news-out.google.com!m134ni893itb.0!nntp.google.com!c26no422151itd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 10 May 2017 09:19:18 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2601:191:8303:2100:4c0f:e82:ed51:5ed8; posting-account=fdRd8woAAADTIlxCu9FgvDrUK4wPzvy3 NNTP-Posting-Host: 2601:191:8303:2100:4c0f:e82:ed51:5ed8 References: <0fc56bf7-1cfa-4776-9c47-a573db315c5f@googlegroups.com> <7b0c08eb-be62-4d14-ae99-cad038ad0a62@googlegroups.com> <077e7f6a-5a7b-4b88-a16f-7672aec18a17@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Portable memory barrier? From: Robert Eachus Injection-Date: Wed, 10 May 2017 16:19:18 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Received-Body-CRC: 2739624304 X-Received-Bytes: 4977 Xref: news.eternal-september.org comp.lang.ada:46745 Date: 2017-05-10T09:19:18-07:00 List-Id: On Tuesday, May 9, 2017 at 3:57:50 PM UTC-4, Randy Brukardt wrote: > "Robert Eachus" wrote in message=20 > news:077e7f6a-5a7b-4b88-a16f-7672aec18a17@googlegroups.com... > ... > >The compiler will play some games, and certainly will leave Write_Index = in=20 > >a register if possible. >=20 > It better not is Write_Index is Atomic. First, if FIFO has Atomic_Components, then it is not possible. Atomic_Comp= onents would be overkill, but I haven't seen those declarations here. If F= IFO has just Volatile_Components (or no attribute) then this is possible. = But what is "this"? >=20 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 syste= m is cache-coherent. But that is a detail. What I was specifically referr= ing to was that there are two subexpressions Write_Index+1. As far as I ca= n tell, if there are no synchronization points between them, the (overall s= ystem including) the compiler can do one read of Write_Index, then evaluate= the expression once--or twice. Why evaluate twice? (Other than the write to FIFO being a synchronization p= oint?) Hardware magic may combine the increment with the move, through a p= ostincrement addressing mode. It would then write the incremented register = copy to Write_Index. One read, one write. Same as if it did common subexp= ression elimination. It doesn't need to READ Write_Access twice. I hope I'= m right, because anything else is silly. If a synchronization point did oc= cur between the two reads, then the in register copy of Write_Index, or Wri= te_Index + 1, if the implementation wants to keep that around instead, must= be spoiled. What if Write_Address is assigned to a special address which other hardware= can access? Doesn't matter. Think of the cache system as treating addres= ses as names, and moving them around. As long as everyone sees the same ve= rsion of that name, the contents of the location named are the only reality= we can be concerned with. Since CPUs now contain the (physical) memory ma= nagers, as well as cache, the "external effect" of a program has to be inte= rpreted as the view of memory offered by the CPU. Nothing else is availabl= e. (Writes to disk, or to the display screen are all memory writes from th= e CPU's viewpoint.) There is another issue here, which we need to allow compilers to get right.= Assume that the records in FIFO are X bytes long. A common compiler opti= mization is to use a value FIFO'Address + X x Write_Index instead of Write_= Index to do the writes. Is that legal? Or better, under which attributes = of FIFO and Write_Index is the system allowed to do that optimization? > Only the compiler vendor need worry about this level of discussion.=20 > Honestly, I doubt anyone else is qualified. (I'm not, and I AM a compiler= =20 > vendor... ;-) I used to be a compiler writer, on at least three Ada compilers, but the de= ep level understanding of what is going on comes from my work on radar syst= ems. There access times in microseconds are important, and sometimes in na= noseconds. (I think the worst real-time requirement I ever saw was for 200 = nanoseconds. Ouch!) =20