volatile: a summary

[Peter J Desnoyers]

...
[Ross Cunniff argues that you could defeat a compiler 'manual' of 
volatile locations; Chris Torek argues that extending the manual would
take care of the problem.]

I think that there are things out there not dreamt of in Chris'
philosphy. For instance, if I have an i/o chip that does complicated
dma, how do you tell the compiler that when I add `buffer' to a
certain queue, all locations starting at &buffer +
sizeof(buffer.header), for &buffer.length {bytes/words/bits} are
volatile until the buffer is taken from another queue?  Will your
mechanism work for another, even more complicated dma scheme? What if
you can change the dma model by writing to a device register?

One (unrelated) deficiency I see in |volatile| involves the generation
of spurious writes. In a perfect world, *p = x would generate one
write and no read cycles, at least if *p were volatile. (Read and
write do screwy things with some dumb i/o devices.) I don't have a
copy of the draft standard, but I would assume that this is the sort
of thing that ANSI would never dream of specifying, as it might
prevent a correct implementation on some architecture. I hope that the
people who write cross-compilers keep this in mind when they add ANSI
features, but from what I've seen of current cross-compilers, I don't
have much hope that they will concentrate on making their products
useful. (1/2 :-)

				Peter Desnoyers
				peter at athena.mit.edu