Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!limes
From: limes@sun.uucp (Greg Limes)
Newsgroups: comp.lang.c
Subject: Re: volatile
Message-ID: <51431@sun.uucp>
Date: 30 Apr 88 03:53:05 GMT
References: <20345@pyramid.pyramid.com> <502@wsccs.UUCP>
Reply-To: limes@sun.UUCP (Greg Limes)
Organization: Sun Microsystems, Mountain View
Lines: 28

In article <502@wsccs.UUCP> terry@wsccs.UUCP (Every system needs one) writes:
[previous junk removed for brevity]
>	Yes, but why is
>		volitile int foo;
>	better than
>		int foo;	/* VOLITILE*/
>	Except for the optimizer?

The first not only documents for the user that "foo" may be changed
outside the expected flow of control of the program (i.e. by hardware
or by a signal handler), but making it a part of the language forces
optimiser designers to leave open this trapdoor. It also standardises
where they will put the trapdoor, if/when they realize that programmers
need to be able to break out of the dreaded
	while (!signal_caught);
loops ... try running the previous line through the SunOS 4.0 compiler
at any optimisation level higher than about, say, -O1 ...

Compiler technology is getting really good, and we need a way to tell
the optimisers that strange things can happen. Frankly, I need volatile
so I can let the good optimisations rip on my code, without breaking
the communcation lines between mainline and interrupt-level; without
volatile, I am forced to miss the whole boat. Those of you who do not
want volatile, fine; ignore it when you see it, do not use it, and
compile with your optimisers lobotmized. I want to use all the nifty
stuff they jammed into "-O4".
-- 
   Greg Limes [limes@sun.com]				frames to /dev/fb