Optimization, volatile (was Re: volatile)

Jim Shankland jas at llama.rtech.UUCP
Sun Apr 24 08:58:00 AEST 1988


In article <13074 at brl-adm.ARPA> dsill at NSWC-OAS.arpa (Dave Sill) writes:
>Terry Lambert writes:
>>Basically, if it works without -O, it should work with -O, regardless of what
>>the compiler writer's optimization does to achieve its goal.  If this makes
>>writing compilers harder, so what?
>
>This bears repeating.  There should be no circumstances under which
>the semantics of the language are changed by a flag to the compiler.

However, you didn't repeat it.  Your assertion is reasonable, Lambert's
is not.  The world is full of (strictly speaking) incorrect C programs
that work just fine because of some accident of hardware, the compiler
used, etc.  A good optimizer can "break" programs (actually, cause existing
bugs to become manifest) just as porting a C program from a VAX to a
Sun can.

Perhaps that sounds like nitpicking; I don't think it is.  To get back
to "volatile":  it provides a portable way to declare storage objects
that may change without notice, and thus is useful in writing portable
(not necessarily portable *everywhere*, but plenty portable for may uses)
programs that access device registers, use shared memory, signal handlers,
etc. (we've been over the whole list).

The alternatives that have been mentioned include:

	(1) "Just don't do all that silly optimization".  Then, as Dennis
	Ritchie points out, it's even possible to write system software in
	C without "volatile".  Somebody else (don't remember who)
	said something to the effect that optimization won't improve
	performance by more than 20-30% anyway, so why bother?  I
	am amused to think what my employer's customers might say if
	we told them that we could have easily made our software 20-30%
	faster, but couldn't be bothered for such an inconsequential gain.

	(2) "If you need `volatile', don't use C."  I agree, it's
	certainly more comfortable in the lifeboat once you've pushed
	some of your fellow passengers into the shark-infested waters.
	I'm just not crazy about being the one pushed out, especially
	since we "systems software" types were in this boat first.
	Tell you what:  let's push out the N.A. types instead.  They
	don't seem all that unhappy with FORTRAN, anyway.

	(3) "Let implementers of optimizing compilers come up with their
	own pragmas that can turn off certain optimizations where they
	will be destructive."  In other words, let each implementer
	add "volatile" in her own way.  However, the semantics of
	"volatile" are well-defined and broadly useful.  Making its
	use non-portable is gratuitous.  As an aside, the arguments
	over "volatile int mutex; ... ++mutex;" are a red herring.
	"volatile" clearly does not guarantee atomicity, nor is it
	intended to.

What's that?  You need the soapbox I'm standing on to do the laundry?  Oh.

Bye.


Jim Shankland
  ..!ihnp4!cpsc6a!\
               sun!rtech!jas
 ..!ucbvax!mtxinu!/

	And I will show you something different from either
	Your shadow at morning striding behind you
	Or your shadow at evening rising to meet you;
	I will show you fear in a handful of dust.

			-- T. S. Eliot



More information about the Comp.lang.c mailing list