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!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: STM32F4 GNAT Run Time System - roadmap
Date: Mon, 7 Dec 2015 20:11:15 -0600
Organization: JSA Research & Innovation
Message-ID: <n45e84$rpr$1@loke.gir.dk>
References: <lyzj49qecx.fsf@pushface.org> <ml96i2$3qs$2@dont-email.me>
 <lya8pnh1dq.fsf@pushface.org>
NNTP-Posting-Host: rrsoftware.com
X-Trace: loke.gir.dk 1449540676 28475 24.196.82.226 (8 Dec 2015 02:11:16 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Tue, 8 Dec 2015 02:11:16 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Xref: news.eternal-september.org comp.lang.ada:28698
Date: 2015-12-07T20:11:15-06:00
List-Id: <comp.lang.ada>

"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 think someone here originally proposed that (or at least something like 
it); it took us quite a while to come around to that view, mainly because of 
compatibility concerns. But there is also the concern of doing something 
unexpected.

Anyway, I don't expect that there is much use of that GNAT-specific aspect 
once the changes are approved (probably will happen next year at our next 
meeting).

                                                     Randy.