Re: Handling Addressing Errors

["Nick Roberts" <Nick.Roberts@dial.pipex.com>]

I think Charles' query with the RM95 is largely addressed by the AARM, if I
may quote AARM C.6:

16   For a volatile object all reads and updates of the object as a whole
are
performed directly to memory.

        16.a   Implementation Note:  This precludes any use of register
        temporaries, caches, and other similar optimizations for that
object.

and:

20   {external effect [volatile/atomic objects]} The external effect of a
program (see 1.1.3) is defined to include each read and update of a volatile
or atomic object.  The implementation shall not generate any memory reads or
updates of atomic or volatile objects other than those specified by the
program.

        20.a   Discussion:  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.

        20.b   The rule above and the definition of external effect are
        intended to prevent (at least) the following incorrect
optimizations,
        where V is a volatile variable:

         20.c  X:= V; Y:=V; cannot be allowed to be translated as Y:=V;
               X:=V;

         20.d  Deleting redundant loads: X:= V; X:= V; shall read the
               value of V from memory twice.

         20.e  Deleting redundant stores: V:= X; V:= X; shall write into
               V twice.

         20.f  Extra stores: V:= X+Y; should not translate to something
               like V:= X; V:= V+Y;

         20.g  Extra loads: X:= V; Y:= X+Z; X:=X+B; should not translate
               to something like Y:= V+Z; X:= V+B;

         20.h  Reordering of loads from volatile variables: X:= V1; Y:=
               V2; (whether or not V1 = V2) should not translate to Y:=
               V2; X:= V1;

         20.i  Reordering of stores to volatile variables: V1:= X; V2:=
               X; should not translate to V2:=X; V1:= X;

I think the additional notes pretty well settle any doubts Charles may have,
except perhaps that the wording in the RM (rather than just the AARM) might
have been stronger or more explicit.  On the assumption that all compiler
writers will have read and inwardly digested the AARM (as well as the
Rationale, the AI95s, etc.)*, I think Charles can feel reasonably safe.

-------------------------------------
Nick Roberts
-------------------------------------

*e.g. me ;-)