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: border1.nntp.dca.giganews.com!nntp.giganews.com!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Simon Clubley Newsgroups: comp.lang.ada Subject: Re: Ada-Comment proposals (version 3) Date: Sun, 13 Jul 2014 18:16:50 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Date: Sun, 13 Jul 2014 18:16:50 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="bf411e8985db1bfacf0e5cbbbee80710"; logging-data="5947"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/qnXSjNCR/MVl5EBUP8xbYsav/Y2VZBCw=" User-Agent: slrn/0.9.9p1 (Linux) Cancel-Lock: sha1:KX4/RqodN6KaOKnkBSqLy9vExDc= Xref: number.nntp.dca.giganews.com comp.lang.ada:187569 Date: 2014-07-13T18:16:50+00:00 List-Id: On 2014-07-13, Niklas Holsti wrote: > On 14-07-13 19:54 , Simon Clubley wrote: >> I've restructured issue 1 to turn it into a general partial aggregates >> proposal. The atomic updating of device register bitfields discussion >> is still pretty much the same but the additional comments and examples >> from Niklas make it a more general proposal. >> >> Niklas, since I have included your words and examples directly, can you >> make sure you are happy with what I have included please ? > > Quite ok, thanks. I have just one additional comment: > >> 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, not just an atomic read followed by an atomic > write of a new value, where other accesses to the record variable can > occur between the read and the write. Wikipedia defines > "read-modify-write" as an atomic update, giving the "test-and-set" > instruction type as one example. > 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. I'll see about tweaking the language to make that more clearer however. > It would be safer to write something like this: "the compiler would > generate an atomic read of the whole record variable into a > compiler-created temporary (perhaps a register), followed by an update > of the temporary according to the component updates listed in the > partial aggregate, and ending by an atomic write of the whole updated > value into the record variable". > > 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. 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. And yes, I know that people should not be writing code which depends on compiler behaviour. :-) Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world