Path: utzoo!dciem!nrcaer!scs!spl1!laidbak!att!pacbell!ames!umd5!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.lang.c Subject: Re: volatile Message-ID: <11783@mimsy.UUCP> Date: 2 Jun 88 00:37:18 GMT Article-I.D.: mimsy.11783 References: <20345@pyramid.pyramid.com> <502@wsccs.UUCP> <51431@sun.uucp> <5590@bloom-beacon.MIT.EDU> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 92 >In article <11709@mimsy.UUCP> I claimed that >>In the limit, the compiler may simply assume that all variables are >>volatile and aliased; it will then act much like the C compilers we >>have been using on Unix systems. It may produce suboptimal code, >>but it will produce correct code, and it does not need a `volatile' >>keyword. This last point---that C without `volatile' has been used for systems work---seems to have been ignored by those who claim that volatile is necessary. (Note that I claim only that it is unnecessary, not that it is bad.) In article <5590@bloom-beacon.MIT.EDU> peter@athena.mit.edu (Peter J Desnoyers) writes: >C compilers on most Unix systems do not assume that all variables are >volatile, True enough: register variables are not considered volatile. >and they certainly do not assume that all memory is volatile. Let us try an experiment: f() { register int i, *ip; i = *ip; i = *ip; } produces movl (r10),r11 # i = *ip movl (r10),r11 # i = *ip That sure looks like the code I would expect from volatile int *ip; and not like the code I might expect without it (since `i' is unused, I would be unsurprised to find the body of f() elided altogether). (In fact, unless the `-i' flag is used, the 4BSD optimiser /lib/c2 can make some changes to memory references that can cause trouble, so this is somewhat weak.) >In the first case, the program results would be at best completely >undefined, and in the second case code generation would be impossible, >as there would be no guarantee that the processor would ever get to >see it before it was modified. This does not follow. The virtual machine semantics provided in the absence of volatile declarations are still there in the presence of such declarations; volatile simply adds a constraint, or a set of constraints. The precise constraints added are machine-dependent, but the virtual machine semantics do not magically vanish. >>[fancy automatic volatility detection] requires knowledge of the >>machine internals .... >Most compilers know nothing of a machine's internals. And this is considered a virtue. I say not. >... Which physical memory locations are going to be volatile may not >be known when the program is written, Were that the case, not even the programmer would know where to insert `volatile' declarations. >and certainly not when the compiler is written. Quite probably not. Hence it should be runtime configurable. (This is a `quality of implementation' issue, given the existing draft standard.) >The situation is similar for MSDOS machines. The compiler does not know >whether a piece of code will be executed with EMS, EEMS, company X's >I/O board in slot Y, or all of the above. The programmer does. Then the programmer can select which map file the compiler should see, so that the compiler can error-check the programmer's declarations, or in a more ambitions system, correct or create them. >Don't be a Unix chauvinist. All I did was to hold up one example of a number of systems that have managed without `volatile': an existence proof, as it were, that volatile is *not necessary*. I can use a similar proof to show that C is not necessary---e.g., MVS. Does that make me an IBM chauvinist? (That I detest MVS is irrelevant. I also happen to like `volatile'.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris