gillies@uiucdcsp.cs.uiuc.edu (04/10/88)
That's a very good point: Since volatile is so machine/application
specific (do I need it on a stack machine? unlikely!) It may be a
bad idea to nail it down in a particular way. For instance:
1. Do we want volatile to apply to individual variables?
2. Or would the programmer rather have a directive that makes a clump of
variables volatile? After all, it's a pain to make an entire
module "volatile"
3. Perhaps we want to have stretches of code that are "volatile",
(The HP method?) and in other places allow the variables to live in
registers or whatever.
4. I'm sure you can imagine useful applications for the other situations.
Can you honestly predict what these shared-memory multiprocessing guys
really need? Will they have to reimplement the feature themselves?
If so, then the answer is : Do not put it in.
Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois
{gillies@p.cs.uiuc.edu}tada@athena.mit.edu (Michael Zehr) (04/11/88)
In article <77200031@uiucdcsp> gillies@uiucdcsp.cs.uiuc.edu writes: > >Can you honestly predict what these shared-memory multiprocessing guys >really need? If i understand what is meant by volatile, then there are uses on regular machines too. For example: while(!(user_interrupt)) { /* do nothing */ } where user_interrupt is a global variable that is changed by an asynchrous interrupt (from a keyboard, mouse, etc.). I'm running on a standard vaxstation II, so there's no fancy shared memory going on, and it's only one process that's executing all the code. I've had some real problems getting the compiler to do what i want, because it keeps on wanting to optimize it out of a loop, or into a register, or something. ------- michael j zehr "My opinions are my own ... as is my spelling."
aglew@urbsdc.Urbana.Gould.COM (04/14/88)
>> extern volatile int user_interrupt; >> while (!user_interrupt) >> sleep(1); >> >> Carrick Talmadge clt@newton.physics.purdue.edu > >Please do not misunderstand me, I would like to see "volatile" >added -- but why would it be required above? If "user_interrupt" >is an external variable, then the compiler is not free to assume >that it will not change across a function call. Since you call >sleep() in the loop, the compiler is not free to use the cached value >of user_interrupt from the previous iteration. > >Greg LImes [limes@sun.com] I have some hope of seeing decent cross-procedural and global analysis in production C compilers in my lifetime ;-}. In which case, the compiler may be able to prove that user_interrupt is not modified by any function called... So, what do you want: "synchronous volatile" and "asynchronous volatile"? aglew@gould.com
guy@gorodish.Sun.COM (Guy Harris) (04/16/88)
> I have some hope of seeing decent cross-procedural and global analysis > in production C compilers in my lifetime ;-}. In which case, the > compiler may be able to prove that user_interrupt is not modified > by any function called... Or it may not, given that "sleep" may be dynamically bound and therefore the compiler may have no way of knowing what procedure "sleep" is, and therefore has to limit its cross-procedural analysis.