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: border2.nntp.dca1.giganews.com!nntp.giganews.com!newspeer1.nac.net!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!news.stack.nl!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: Forcing GNAT to use 32-bit load/store instructions on ARM? Date: Mon, 7 Jul 2014 17:38:54 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <0e0b9ac2-e793-4cc5-8d8d-d3441ca28a58@googlegroups.com> <1j7b0m3yptffy$.1cztnkty8elrv$.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1404772735 10953 69.95.181.76 (7 Jul 2014 22:38:55 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 7 Jul 2014 22:38:55 +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: number.nntp.dca.giganews.com comp.lang.ada:187439 Date: 2014-07-07T17:38:54-05:00 List-Id: "MatthiasR" wrote in message news:lpcck1$vtv$1@dont-email.me... > Randy Brukardt wrote: > >> Right. If the OP really did exactly as he said, then GNAT has a bug (no >> matter what his declaration was). [But I've seen plenty of cases where >> someone (including me) thought they'd tried something when they really >> had >> not for one reason or another.] > > According to the RM, the compiler must not divide a read or write from/to > a > variable with pragma/aspect 'atomic' into multiple reads/writes. There is > nothing said, that the variable always has to be read/written as a whole. > So > it seems to be perfectly OK to write only one byte of a 32 bit variable, > if > a value has been assigned to only a part of a record which is contained in > this byte. No. C.6(22/2) surely applies. (All atomic objects are also volatile objects.) Anyone claiming that C.6(22/2) does not apply to a load/store of part of an object is seeing what they want - that would be inconsistent with the way such wording is intepreted in the rest of the standard. But any attempt to write of a record component of an atomic object necessarily must violate either C.6(20) or C.6(22/2). (Either you don't access all of the bits, or you have to have a read not in the source code to read the bits that you aren't going to write.) From that I conclude that Ada doesn't (really) support atomic composite types (and any attempt to declare such a thing ought to be rejected, since the language provides no other possibilities). I doubt any compiler will do that for practical reasons. Since C.6(22/2) is Implementation Advice, a compiler is allowed to ignore it if it documents that it does so. That's probably what GNAT is doing here, but clearly that's harmful (as noted by this discussion). I'd rather that the implementation reject any assignments for which it cannot make this guarantee, but I suppose the language gives no justification for doing so. (That's a common problem in Chapter 13/Annex C features.) Does GNAT at least give a warning? Clearly, we need a partial aggregate syntax (it's the only way for an atomic record write to make sense), and that needs to be clear that it includes both a read and a write of the object for the purposes of volatile variables. Probably someone should submit this problem to Ada-Comment for study in the next version of Ada (whenever that might be). > There is something said about this topic in the latest GNAT docs: > https://docs.adacore.com/gnat-unw-docs/html/gnat_ugn_8.html#SEC97 > > They recommend to use a temporary variable to ensure an access to the > record > variable as a whole. Right. Partial writes of atomic objects shouldn't be allowed at all, and thus the programmer should never write one. > That is not really elegant, because records with representation clauses, > directly mapped onto hardware registers, look like the most natural way to > access these registers. That *is* the most natural way to access those registers. But you can never access a *part* of a register, you always have to read or write the entire register at a time. Ada makes you make that explicit in your code, thus a temporary is required (pending new syntax). > Reading Ada books, one even could get the impression > that record represenation clauses are made primarily for this purpose. It is. > Unfortunately there seem to be no way to force a specific access width, so > this feature is not really useable (without the mentioned workaround with > the temporary variable) on architectures where the allowed access width is > not uniform over the whole address range. No, you're looking at this the wrong way. If you write this in C, you read the entire register and then do some sort of bit-mask, and then write the thing back. You have to do that same thing in Ada, just using the record type instead of the bit mask. Ada replaces the bit masking operations by more readable record component accesses; it doesn't suddenly allow you to write something that you couldn't possibly write in C [a direct write of part of a register]. (Whether Ada *should* have allowed you do to that is a totally different question and relatively irrelevant at the moment because the language isn't likely to support anything new in the near future.) Randy.