Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!bellcore!faline!thumper!ulysses!hector!jss
From: jss@hector.UUCP (Jerry Schwarz)
Newsgroups: comp.lang.c
Subject: Re: volatiles
Message-ID: <10242@ulysses.homer.nj.att.com>
Date: 19 Apr 88 21:06:53 GMT
References: <1394@pt.cs.cmu.edu> <1530@dataio.Data-IO.COM> <1412@pt.cs.cmu.edu> <2584@ttrdc.UUCP>
Sender: netnews@ulysses.homer.nj.att.com
Reply-To: jss@hector (Jerry Schwarz)
Organization: AT&T Bell Labs, Murray Hill
Lines: 34

In order to understand "volatile" we first must first be able to
answer the question: "what is the meaning of a C program"?
It isn't the mapping of input to output.  I/O takes place only
through library functions and unhosted C environments don't even have
such functions.

It is clear that the meaning is somehow connected to the fetch/store
history of global variables and perhaps the call history
to some foreign (i.e. not written in C) functions, and even worse,
external events that cause C functions to be called.

But does this mean that the fetch/store history of all global
variables  is significant?  And must the compiler assume that there
is no relation between what the code stores at a location and what it
fetches later?

Prior to the introduction of "volatile" there was no satisfactory
answer to these questions.  To answer "yes" constrains the code
generator too much and results in slower compiled code. To answer
"no" results in confusion about the meaning of a C program and to
disputes about what an optimizer is allowed to do.

The introduction of "volatile" changes the situation.  The meaning of
a C program is now related to the fetch/store history of "volatile"
and only "volatile" locations.  Thus adding "volatile" to the
language doesn't make a minor change in the meaning of C programs
that use it.  If makes a radical change in the concept: "meaning of a
C program".

I still think that it's a good idea but I no longer think (as I used
to) that it is a simple one.

Jerry Schwarz
Bell Labs, Murray Hill