volatile

[~XT4103000~Marc Mengel~C25~G25~6184~]

In article <11566 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
$So?  For any of these to occur, the CIO PP must be told where the
$objects reside.  The telling points out the volatility.  It takes a
$great deal of cleverness, but a truly smart flow analysis routine will
$note that
$ [code initializing DMA deleted]
$causes `count' words at the location given by `buf' to become uncertain
$until the interrupt occurs.  It would be nice if, even though someone
$forgot to say so, the compiler would complain about the following line:
$	if (buf[2 * count - 1] == '\n')
$...

Hmm.. I would agree with you here only if C had a COBOL style statement
declaring what machine a program is being compiled for.  Your suggestion
would fail miserably if I compiled a program for Brand X 68020 Box on
a Brand Y 68020 Box.  It would also have to know if the program was
being compiled to run on the bare machine, or under operating system Z,
etc.

Certainly you can postulate a machine description file detailed enough
to allow this sort of analysis, but that would *not* be C, you will
instead have built a new language C-plus-machine-description.

$There are pragmatic reasons not to find all cases of volatility (it may
$take too long on a given machine), but it can be done.  When it can be
$done, it should be done.

Certainly agreed; however if a compiler claims to know that memory
location 0x1234567 is a hardware register that *must* be volatile,
it will be wrong in cross-system-same-cpu development environments,
when creating new operating systems, etc.  The compiler cannot know
enough about the environment it is compiling into to detect volatitlity
because the environment may have been created after the compiler, and
may even be under development.

$-- 
$In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
$Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris


-- 
 Marc Mengel	

 attmail!mmengel
 ...!{moss|lll-crg|mtune|ihnp4}!cuuxb!mmengel