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: Forcing GNAT to use 32-bit load/store instructions on ARM?
Date: Wed, 02 Jul 2014 01:38:09 +0300
Organization: Tidorum Ltd
Message-ID: <c1gribF9j9oU1@mid.individual.net>
References: <0e0b9ac2-e793-4cc5-8d8d-d3441ca28a58@googlegroups.com>
 <lou82i$7u2$1@dont-email.me>
 <ca6f05d3-c469-4abc-92df-54aa605f41ba@googlegroups.com>
 <lov6bu$j0s$1@dont-email.me> <c1glt9F8dvoU1@mid.individual.net>
 <lov8m0$433$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: individual.net cEIUvRlCxZPMi+SQdmqo0gO6z/WKyszooHKfxkhBiPtQTLxdB8
Cancel-Lock: sha1:iKB0QhpbmoGZRM31Un7MBkD4ETc=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
In-Reply-To: <lov8m0$433$1@dont-email.me>
Xref: news.eternal-september.org comp.lang.ada:20679
Date: 2014-07-02T01:38:09+03:00
List-Id: <comp.lang.ada>

On 14-07-02 00:20 , Simon Clubley wrote:
> On 2014-07-01, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
>> On 14-07-01 23:40 , Simon Clubley wrote:
>>> On 2014-07-01, daniel.dmk@googlemail.com <daniel.dmk@googlemail.com> wrote:
>>>> So could there be a problem with GNAT's Atomic on ARM?
>>>>
>>>
>>> Yes, big time.
>>
>> No. The Atomic guarantee only applies to read/write of the whole record.
>> My earlier post in this thread was in error.
>>
> 
> That's interesting, and depressing, as it reduces the usefulness of
> Atomic hugely.
> 
> When c.l.a talked a few weeks ago about syntax for the atomic update
> of multiple bitfields at the same time, I had thought the general
> view was that Atomic on a record resulted in register updates in units
> of the record size when updating a single bitfield, but that's clearly
> not the case as you have just pointed out.

As I remember, the new syntax ideas in that discussion were meant to
update some bitfields in an atomic record as part of a read, modify,
write sequence, accessing the whole record without using a temporary
variable to hold the value. So Ada's rule for Atomic was included and
assumed in that discussion. I am ashamed for forgetting it... maybe
there have been too many midnight-football-viewing sessions lately :-)

> I think this whole area of the atomic updating of multiple bitfields is
> something which needs work in Ada especially now the above revelation
> means Ada is even weaker in this specific area than I thought it was.

I don't think the weakness is serious. Using a temporary variable to
ensure whole-record access is a pretty clean work-around, IMO. But the
new aggregate-like syntax suggested in the earlier discussion could be
used for other things, too, so I am still in favour of it.

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