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.2 required=5.0 tests=BAYES_00,FROM_WORDY, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e8d2c0ed82daf4da X-Google-Attributes: gid103376,public From: "Nick Roberts" Subject: Re: Handling Addressing Errors Date: 1999/03/18 Message-ID: <7cttko$348$1@plug.news.pipex.net>#1/1 X-Deja-AN: 456541070 References: <1999Mar3.212443.1898@nosc.mil> <7bm0v3$933$1@nnrp1.dejanews.com> <1999Mar18.005620.19189@nosc.mil> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Organization: UUNET WorldCom server (post doesn't reflect views of UUNET WorldCom) Newsgroups: comp.lang.ada Date: 1999-03-18T00:00:00+00:00 List-Id: 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 ;-)