Re: Forcing GNAT to use 32-bit load/store instructions on ARM?

[Simon Wright <simon@pushface.org>]

"Randy Brukardt" <randy@rrsoftware.com> 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).