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.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Ada-Comment proposals (version 3) Date: Mon, 14 Jul 2014 00:05:42 +0300 Organization: Tidorum Ltd Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: individual.net iAKPqim8EvyAgonlcFCupgPmx0/BwJvvMwksfzRYblKiwRhtsa Cancel-Lock: sha1:3RWDaqLZWKka2l9GwAB1ni7nwv4= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: Xref: number.nntp.dca.giganews.com comp.lang.ada:187571 Date: 2014-07-14T00:05:42+03:00 List-Id: On 14-07-13 21:16 , Simon Clubley wrote: > On 2014-07-13, Niklas Holsti wrote: >> On 14-07-13 19:54 , Simon Clubley wrote: >>> For an Atomic record, the compiler would generate a Read-Modify-Write >>> sequence >> >> I'm afraid that saying "Read-Modify-Write" may be misunderstood to mean >> a fully atomic update, ... > > This was one of the things which was discussed with Randy a few days > ago. At that time, it was made clear by Randy that Atomic, as applied > to Ada, only ever meant the read was atomic and the write was atomic. > The overall sequence itself is never considered to be an atomic > operation. Exactly, so it is not "read-modify-write" as Wikipedia defines this term (and as I, too, understand it). > I'll see about tweaking the language to make that more clearer however. Good. >> This brings to mind an interesting question: if the processor has some >> fully atomic read-modify-write instructions, and the semantics of one of >> these instructions matches the way the record variable is updated with a >> partial aggregate, is the compiler allowed to use that read-modify-write >> instruction? I don't know if such instructions always work with >> memory-mapped peripheral registers -- for example, their timing in terms >> of clocks between the read and the write may be different. >> > > We would have to be _very_ careful here that we didn't introduce > behaviour which could be platform specific. I should have been clearer in my comment -- I did not really mean that this question should be added to this Ada-Comment, rather I meant to ask if someone knows of examples of peripheral registers for which read-modify-write instructions do not work. > For example, we would not want people to write code which didn't > consider what happens during an interrupt simply because that wasn't > an issue on the original platform due to the generated code emitted > by the compiler. Does this mean that you want to forbid Ada compilers from using read-modify-write instructions? It is always possible to write platform-specific code, intentionally or accidentally. In particular, the execution timing and therefore the locations of preemptions and interrupts is platform specific. For example, a shared but unprotected variable may work reliably on one platform but fail due to race conditions on another. Therefore, I would let the compiler use read-modify-write instructions if it wants to, and as long as the ARM is obeyed. I don't see it as an important problem that this would make the some updates fully atomic on some platforms, while the same source code result in a non-atomic update on another platform. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .