Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!hc!pprg.unm.edu!unmvax!ncar!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: The world is not ready for 'volatile'
Message-ID: <15258@mimsy.UUCP>
Date: 4 Jan 89 12:56:40 GMT
References: <141@bms-at.UUCP> <275@twwells.uucp> <15166@mimsy.UUCP> <9273@smoke.BRL.MIL>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 46

>In article <15248@mimsy.UUCP> I claimed that
>>For folks concerned with portability, the word `volatile' does not
>>exist in the language (with one exception), since the actual effect of
>>the volatile qualifier is compiler-dependent.

In article <9273@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
>No, that's wrong.  A conforming compiler is obliged to generate code
>for "volatile" object accesses strictly in accordance with the
>virtual machine model (no caching).  It is OTHER mechanisms for
>accessing a volatile object during execution that are not specified.

This is a difference that makes no difference.  It can therefore be
ignored with impunity.  Or do you have some way to tell, within
strictly conforming code, that the compiler generated code that is
not strictly in accordance with the virtual machine model?

When it comes to figuring out what `register volatile v' means (versus
simply `register v'), consider the following:

  - `register' may not be applied to global and static variables.
  - The compiler (not the linker, nor anything else) chooses the
    location of all automatic (stack) variables.

This therefore implies that the compiler can easily tell whether the
register or memory it chooses for that variable is in fact volatile,
and can (and in all compilers that now exist---if you can find one
where this is false, let me know---does) choose storage that is not
volatile.  [By the way, using mmap on your entire stack segment after
using up all the local machine registers is cheating.  :-) ]

A rather more shaky claim, yet one that is partly believable, is that
`auto volatile' is also never needed (with that one exception).  The
major difference is that one can take the address of a non-register
automatic; it *is* conceivable that one can feed the address of a
program variable to a device and have that device make use of it.  But
since the compiler chooses the address of a register variable AND DOES
NOT EVER LET YOU KNOW WHAT IT IS, there is no way ever to get a handle
on that variable.  The compiler can assign it `real memory' space and
rest assured that that space is indeed not volatile.

None of the above applies to `register volatile *' (where the pointer
itself is not the volatile object, the volatility being in the object
to which it points).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris