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: border2.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Simon Clubley Newsgroups: comp.lang.ada Subject: Re: Oberon and Wirthian languages Date: Wed, 23 Apr 2014 12:16:16 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <1ljwj8f.1wqbhvuabsdw1N%csampson@inetworld.net> <51c7d6d4-e3be-44d5-a4ce-f7e875345588@googlegroups.com> <%J32v.70539$kp1.45343@fx14.iad> <8761m535e4.fsf_-_@ludovic-brenta.org> Injection-Date: Wed, 23 Apr 2014 12:16:16 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="e458ff8b81bc0c159989eb0e36c6e372"; logging-data="4203"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX180AJWsuIV1CF8jgb2ptBDEqXb/jgPSoOQ=" User-Agent: slrn/0.9.8.1 (VMS/Multinet) Cancel-Lock: sha1:LjRnzum0nMCuqaZu5ZvuhZtZJ2A= Xref: number.nntp.dca.giganews.com comp.lang.ada:186019 Date: 2014-04-23T12:16:16+00:00 List-Id: On 2014-04-22, Randy Brukardt wrote: > "Simon Clubley" wrote in > message news:lj6kfg$jhs$1@dont-email.me... > ... >> Ok, now that's interesting. I would not have assumed the compiler would >> do the read multiple times in this specific case. >> >> I would have assumed the Volatile attribute would be satisfied in this >> specific case by doing the read _once_ at the start of the generated >> code and only generating code to modify the A, B and C bitfields >> before writing everything back in one step by using a single store >> opcode. > > C.6(20): > > The external effect of a program (see 1.1.3) is defined to include each read > and update of a volatile or atomic object. The implementation shall not > generate any memory reads or updates of atomic or volatile objects other > than those specified by the program. > > I see two reads of Rec in the original source code. The above rule means > that an Ada compiler must NOT combine those reads for convinience; it must > do EXACTLY what's in the source code. If you only want one read, you have to > restructure so there is only one explicit read. > > There was a long discussion about this some years ago, and the conclusion > was that combining operations in particular is not allowed for volatile > objects (and all atomic objects are also volatile). > Thanks for the feedback. >From a technical viewpoint, I can see exactly what you are saying and can understand and agree with your reasoning for the general case. However, from a practical viewpoint the example statement was just used to update a subset of bitfields in the register at the same time so one read would be sufficient. I am also very aware of device registers which either return different results on different reads or treat a read as an acknowledge. In the C language replacement discussion I proposed an "atomic using" syntax which would replace C style bitmasks for updating device registers and would guarantee a single read register/apply modifications as required/write register back in one opcode sequence. I wonder if we need something like that for Ada proper so we don't have to read the register into a temporary variable first in order to guarantee a single register read and a single register write while updating a subset of bitfields in the register. Having to use a temporary variable to guarantee a update of, say, a couple of bitfields (out of a possible large number of bitfields) at the same time just feels as if it isn't elegant. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world