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!mx02.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: AI12-0128 (was: STM32F4 GNAT Run Time System - roadmap)
Date: Fri, 11 Dec 2015 14:59:31 +0000
Organization: A noiseless patient Spider
Message-ID: <lyfuz92fqk.fsf_-_@pushface.org>
References: <lyzj49qecx.fsf@pushface.org> <ml96i2$3qs$2@dont-email.me>
	<lya8pnh1dq.fsf@pushface.org> <n45e84$rpr$1@loke.gir.dk>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org;
 posting-host="6f4ba2ce0f80cf6975f919f4f22c2ad9";
	logging-data="9461"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+jiF8WzMKUKzqutWNKxm56+dn1bb4ztPY="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin)
Cancel-Lock: sha1:tR0CY8JwkyvWmZlHS9iifh1wzys=
	sha1:amCNDwrKCoIbYhdosvLYTERRy0w=
Xref: news.eternal-september.org comp.lang.ada:28773
Date: 2015-12-11T14:59:31+00:00
List-Id: <comp.lang.ada>

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Simon Wright" <simon@pushface.org> wrote in message 
> news:lya8pnh1dq.fsf@pushface.org...
>> ...I've not done any evaluation yet aside from noting that they
>> generate the GNAT-specific Volatile_Full_Access aspect, which is
>> noted in the 'under development' version of the GCC docs (so, will
>> likely be in GCC 6). Maybe plain Volatile will do (but users would
>> have to remember to access the whole register explicitly, rather than
>> leaving it up to the compiler to Do The Right Thing); that would be
>> an easy-enough patch.
>
> The ARG has decided on a different direction to fix the problem
> addressed by Volatile_Full_Access; essentially, accesses to
> non-volatile components of atomic objects have to be accessed with a
> read-modify-write cycle. (See AI12-0128-1.) Various parts of Annex C
> will be rewritten to make that make sense.

I see that !example, 4 lines from the end, says
   if Status_Register.Read then -- Illegal.
- should be .Ready

Reading this (several times), I think the effect is that if I mark a
composite object as Exact_Size_Only, and want to change a component, I
must explicitly read-object-to-temp; modify-temp; write-temp-to-object ?

At the moment I've said e.g.

   type Device_Registers is record
      S0 : Interfaces.Unsigned_16;
      S1 : Interfaces.Unsigned_16;
      L0 : Interfaces.Unsigned_32;
      L1 : Interfaces.Unsigned_32;
   end record
   with Volatile;

and let the components inherit the Volatile.

With the new aspect, I think I'd need to say e.g.

   type Device_Registers is record
      S0 : Interfaces.Unsigned_16 with Exact_Size_Only;
      S1 : Interfaces.Unsigned_16 with Exact_Size_Only;
      L0 : Interfaces.Unsigned_32 with Exact_Size_Only;
      L1 : Interfaces.Unsigned_32 with Exact_Size_Only;
   end record
   with Volatile;

?