comp.lang.ada
 help / color / mirror / Atom feed
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Subject: Re: Ada-Comment proposals (version 3)
Date: Mon, 14 Jul 2014 00:05:42 +0300
Date: 2014-07-14T00:05:42+03:00	[thread overview]
Message-ID: <c2gaktFol99U1@mid.individual.net> (raw)
In-Reply-To: <lpuieh$5pr$1@dont-email.me>

On 14-07-13 21:16 , Simon Clubley wrote:
> On 2014-07-13, Niklas Holsti <niklas.holsti@tidorum.invalid> 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
      .      @       .


  reply	other threads:[~2014-07-13 21:05 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-13 16:54 Ada-Comment proposals (version 3) Simon Clubley
2014-07-13 17:53 ` Niklas Holsti
2014-07-13 18:16   ` Simon Clubley
2014-07-13 21:05     ` Niklas Holsti [this message]
2014-07-13 23:45       ` Simon Clubley
2014-07-14  0:24 ` Simon Clubley
2014-07-15 17:20   ` Simon Clubley
2014-07-15 22:11     ` Randy Brukardt
2014-07-15 23:15       ` Simon Clubley
2014-07-15 23:39         ` Adam Beneschan
2014-07-15 23:50           ` Adam Beneschan
2014-07-16  0:05             ` Simon Clubley
2014-07-21 22:02             ` Randy Brukardt
2014-07-21 22:09               ` Simon Wright
2014-07-22  0:26                 ` Randy Brukardt
2014-07-15 23:53           ` Simon Clubley
2014-07-21 22:20             ` Randy Brukardt
2014-07-21 23:06               ` Simon Clubley
2014-07-22  0:24                 ` Randy Brukardt
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox