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!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Forcing GNAT to use 32-bit load/store instructions on ARM? Date: Tue, 08 Jul 2014 07:51:51 +0100 Organization: A noiseless patient Spider Message-ID: References: <0e0b9ac2-e793-4cc5-8d8d-d3441ca28a58@googlegroups.com> <1j7b0m3yptffy$.1cztnkty8elrv$.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx05.eternal-september.org; posting-host="5cbec41b82bafb9ba55107f02585e18b"; logging-data="14951"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/4EPgbyFynMW2YEDDrJoQgZUijIc+ovvY=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (darwin) Cancel-Lock: sha1:7GOak1KmfxXgDxR/nWN3ukN9OAw= sha1:D9UBe7FEXBrsG8x6TjOpC9mHqe4= Xref: news.eternal-september.org comp.lang.ada:20791 Date: 2014-07-08T07:51:51+01:00 List-Id: "Randy Brukardt" writes: > 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. I don't quite understand the conclusion of AI95-00272 in the light of this! (It's expressed in terms of slices of an (atomic) array object, but it would surely apply also to record components if anyone had thought of that). I don't understand why anyone would say that an object was atomic if they didn't want it to be always addressed as a whole (and the prime reason for that must be memory-mapped I/O, given we now have protected objects for inter-task communication). See also the AARM ramification for C6(7), "A slice of an atomic array object is not itself atomic. That's necessary as executing a read or write of a dynamic number of components in a single instruction is not possible on many targets." which strikes me as being back-to-front reasoning. See also C.6(15), "For an atomic object (including an atomic component) all reads and updates of the object as a whole are indivisible.". I can't help wondering whether "as a whole" was a mistake, given that the IA in the AARM, back as far as Ada95, includes "The presumption is that volatile or atomic objects might reside in an ``active'' part of the address space where each read has a potential side-effect, and at the very least might deliver a different value.". > 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? The GNAT RM doesn't contain notes on C.6 IA, and GNAT doesn't give a warning. FSF GCC 4.9.0 and GNAT GPL 2014 (Mac, x86_64) are both (IMO) a little confused (maybe just legalistic) about this: procedure Atom is type R is record A : Boolean; B : Boolean; end record with Size => 32; for R use record A at 0 range 0 .. 0; B at 0 range 31 .. 31; end record; V : R with Import, Atomic, Convention => C, External_Name => "foo"; begin V := (A => True, B => True); V.A := False; V.B := False; V := (A => True, B => True); end Atom; in that the whole-record assignments are followed by an mfence instruction while the component assignments (implemented by a read V, modify, write V sequence of 3 instructions) are not; I think this means that the component assignments are just treated as volatile, borne out by the fact that the -gnatw.d switch (turn on info messages for atomic synchronization) only reports 'info: atomic synchronization set for "V"' for the whole-record assignments. The x86_64 code accesses all 32 bits of V. If it is more efficient on arm to access the relevant bytes for the component assignments, I expect that's what would happen (as reported).