pardo@cs.washington.edu (David Keppel) (03/19/90)
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', 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'? If it is, what is the correct
way to code this function?
;-D on ( A constant question about volatile ) Pardo
--
pardo@cs.washington.edu
{rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo
rfg@ics.uci.edu (Ronald Guilmette) (03/19/90)
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.