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!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: STM32F4 GNAT Run Time System - roadmap Date: Wed, 9 Dec 2015 16:47:08 -0600 Organization: JSA Research & Innovation Message-ID: References: NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1449701229 12428 24.196.82.226 (9 Dec 2015 22:47:09 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 9 Dec 2015 22:47:09 +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:28744 Date: 2015-12-09T16:47:08-06:00 List-Id: "Simon Clubley" wrote in message news:n49suh$en8$1@dont-email.me... > On 2015-12-08, Randy Brukardt wrote: >> "Simon Wright" 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. >> > > Hmm, one of the two I submitted last year. :-) Nice to see it moving > forward. > > What's the general feeling within the ARG about the related AI12-0127-1 > partial aggregate notation proposal, especially as it applies to updating > bitfields within device registers ? How likely is that to happen ? The holdup is that the proposal only covers record aggregates. The similar SPARK feature includes all kinds of aggregates, and of course we'd like to be able to replace the SPARK feature entirely. The problem being that there isn't an obvious extension for array aggregates (it's much messier once multi-dimensional arrays are considered), so it's back in the lab at the moment. I think there is a good chance that it will be adopted down the road, but it's definitely not a slam-dunk. Randy.