🚀 go-pugleaf

In article <11143@june.cs.washington.edu> pardo@june.cs.washington.edu (David Keppel) writes:
>I have a question about the meaning of ``volatile''.  Suppose:
>
>	foo (volatile int *zork) { ... }
>
>	bar()
>	{
>	    int zork;
>	    foo (&zork);
>	    ...
>	}
>
>The behavior that I want is that `zork' can be cached (e.g., in a
>register) in `bar'...

Lets backup.  Your questions are imprecise.

Obviously, the value of the two different things called "zork" are *never*
considered volatile.  To be more precise, the value pointed to by the
"zork" value in bar is considered to be non-volatile, while the value pointed
to by the "zork" in foo is considered to be volatile.

I assume that your questions are really about the pointed to value.

Within bar, new values assigned to the "pointed to" variable need not always be
stored to memory when the abstract semantics of the virtual C machine would
make you think that they should be.

Likewise, within bar, the current value of the "pointed to" variable need not
always be (again) loaded from memory when the abstract semantics of the
virtual C machine would make you think that they should be.

Within foo however, loads and stores of the variable "pointed to" by the
formal parameter named "zork" must be done in an order such that the ordering
of these loads and stores is "correct" relative to other loads and stores of
other volatile variables.

>...but that it must be treated as `volatile' in
>`foo'.  If the optimizer is allowed to to optimize away the
>`volatileness' of zork inside `foo'?

Zork is not volatile.  The thing that the zork parameter of foo() points to
is considered volatile.  The optimizer cannot ignore or override this fact.
Doing so would be a direct violation of the standard, and any implementation
that did this would be non-conforming.


// Ron Guilmette (rfg@ics.uci.edu)
// C++ Entomologist
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.