Re: access to a volatile variable

[Nathan Sidwell <nathan at acm dot org>]

Alexandre Oliva wrote:
> > 4) For volatile complete T, issue a ped-warn and read the
> > object.
> 
> If you add ``unless `-ansi' is given, in which case you shouldn't read
> the object.'', I buy that.
In this case I think that'd be a bad idea. In some cases we do change behaviour
with the -ansi switch, but I believe the change is to reject/warn some programs
with -ansi that we'd accept without -ansi. I don't think there are cases where
we generate different code (no doubt someone will immediately point out some
case of this :-). If we do generate different code we should warn on the
non-ansi case. Overall I think it would lower the quality of implementation to
do so.

> > --> A conforming program could not tell the difference anyway. <--
> 
> I don't get it.  If I know I'm talking to a particular memory-mapped
> device, and I know it will consume a character every time I read from
> it, I *would* be able to tell, wouldn't I?
You would only be able to tell in a non-conforming way. Or put it another way,
if you can tell, you can't be a conforming program. Device drivers are, of
necessity, non-conforming. We'd better give them sensible semantics.
Now, it's a good thing to tell you when you're straying outside the standard,
we even warn when you're not doing so but your code is weird (like `suggest
paren around ...' (ok, so you have to ask for that warning)). My suggestion
does warn for both volatile cases (if you ask -- maybe we should make it
unconditional), but has the same behaviour regardless of the -ansi switch.

If you've got a volatile T object and you really don't want to read it, why on
Earth would you write `object;'? To say 'Ha! I look at it yet do not see, I
laugh in the face of lvalues!' :-)

The code which Bruno had was trying to use `(void)param' to shut up an `unused
parameter' warning. param wasn't volatile, but was a reference type and thus
normally has an implicit dereference -- except for this void context. If you've
got a parameter of type `volatile T &' and you don't want to use it you'd have
to either not name the parameter, or (if/when the G++ parser is fixed) use
__attribute__ ((unused)), or live with the warning. Is this too high a price to
pay?

The semantics of volatile are nearly all supplied by the implementation. IIR,
all the standard says is that at a sequence point all accesses to/from volatile
objects will have happened and be visible to the `external environment'. The
implementation gets to define `external environment'. I believe there is no
guarantee that a compiler won't fold two volatile accesses to the same object
between the same two sequence points together* (this is my recollection from a
discussion several years ago when we were deciding what our C compiler should
guarantee about volatiles). It all comes down to `implementation defined' and
`quality of implementation'.

nathan

* for example
volatile int *ptr = somewhere
int a = *ptr + *ptr;

produced code might be

load r0,[ptr];	//look two loads
load r1,[ptr];
add r0,r0,r1;
membar;		//memory barier cos we accessed some volatiles

Now, the memory system of the cpu has licence to fold the two loads together
(modulo any page table information), because we've not told it otherwise.
Argument for this code generation-> membar is expensive, if we access several
different volatiles we'd like to share the same memory barrier.
Argument against-> surprise! you (might) only touch the device once.

-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
        I have seen the death of PhotoShop -- it is called GIMP
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk