volatiles

Peter J Desnoyers peter at athena.mit.edu
Fri Apr 15 09:33:47 AEST 1988


>In article <1412 at pt.cs.cmu.edu>, edw at IUS1.CS.CMU.EDU (Eddie Wyatt)
writes: 
># [Optimization] assumes that data flow analysis of the code
># can be used to conduct dead code elimination, variable induction,
># migration of loop invariants, etc.  It can not when you have multi-threads 
># of execution with shared variable because in general any of the shared 
># variables may changed at any time.  volatile is just a HACK to make the 
># optimization technique work! 
>

A compiler must make certain assumptions about the operation of a
machine in order to compile a program at all.  Namely, that the
processor functions in a defined manner when instructions are issued,
and that the memory acts in a defined fashion - when data is
written to a location, it can be read back. (of course, you may have
to wait to issue the read instruction on some architectures)

If memory locations are allowed to change their value arbitrarily,
then compilation (never mind optimization) is impossible.  Volatile
exists to allow code which accesses such 'magic' locations to work. Of
course, naive compilation usually works, but that is no guarantee.

@begin(flame)
Finally, to all those people who say "so what, everyone programs on
MSDOS or UNIX": The last company I worked for made real products.
Modems, networks, and other things like that. A lot more money is
spent on boxes - things that make noise when you kick them - than on
software, and a lot of the value of these electronic boxes is
software. Maybe these people just aren't on the net - the company I
worked for isn't. But they are out there, and there are a lot of them.
Much of the code for such imbedded systems is now written in C instead
of assembler, and it needs both optimization and 'volatile' to work.
Some compilers give you /**OPTIMIZE OFF**/, others give you some other
kludge, and others give you nothing.  I've seen some gory code to get
around this problem, and it shouldn't be necessary. 
@end(flame)

				Peter Desnoyers
				peter at athena.mit.edu



More information about the Comp.lang.c mailing list