A different view of volatile

[Chris Torek]

In article <432 at Aragorn.dde.uucp> be at 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 at mimsy.umd.edu	Path:	uunet!mimsy!chris