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!news.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Ada-Comment proposals (version 3)
Date: Sun, 13 Jul 2014 20:53:31 +0300
Organization: Tidorum Ltd
Message-ID: <c2fvciFm8uiU1@mid.individual.net>
References: <lpudki$1ll$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: individual.net k7I5qvHw8DWxvAbXOAVcEAPNmdAvPEm+m3jRktlK1XwNokdE1Q
Cancel-Lock: sha1:rA3QK2ER1F+OSls3ChdsWrbGX+c=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
In-Reply-To: <lpudki$1ll$1@dont-email.me>
Xref: news.eternal-september.org comp.lang.ada:20917
Date: 2014-07-13T20:53:31+03:00
List-Id: <comp.lang.ada>

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.

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.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .