Path: utzoo!mnetor!uunet!husc6!uwvax!oddjob!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.lang.c Subject: Re: A different view of volatile Message-ID: <11412@mimsy.UUCP> Date: 8 May 88 16:57:59 GMT References: <13120@brl-adm.ARPA> <432@Aragorn.dde.uucp> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 39 In article <432@Aragorn.dde.uucp> be@dde.uucp (Bjorn Engsig) provides an example of ordinary aliasing: >static int *pointer; > >set_address(ptr) int *ptr; > { pointer = ptr }; ... >main() > { > /* volatile */ int result; > set_address(&result); This sort of aliasing is considered `normal' in C, and not cause for declaring variables as volatile. After that call to set_address, even though `result' is a local variable, a straightforward compiler (by which I mean one that does not analyse other functions during compilation of main()) would have to consider any function call (not just one to which &result is passed) as a change to `result': main() { int result; addr(&result); result = 1; f(); if (result==1) ... the compiler may not optimise away the test in the `if'. If you remove the call to addr, or allow the compiler to see the code for addr() and/or f() (some can do this at `link' time), and either addr() does not save its parameter in a global or static variable and/or f() does not use the same value (which would then be &result), the compiler may optimise away the `if' test. In (standard) Pascal, pointers may not point at local variables, and any purely local optimisation is therefore safe. The same is true in (standard) FORTRAN. This sort of problem is why `noalias' came into being (and, fortunately, went out again: compilers that do cross-module optimisation will soon be the norm, rather than the exception; here the problem becomes tractable). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris