volatile: a summary

[Chris Torek]

In article <5766 at bloom-beacon.MIT.EDU> peter at athena.mit.edu
(Peter J Desnoyers) writes:
>...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?

Well, how did you tell me?  (I am not sure you *did* tell me.  I
suspect you meant `buffer.length'.  This is the kind of things you
would like to describe [correctly] just once, then be able to refer to
`that horrid little device over there'.)

>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?

If the compiler is to compute its own idea of volatility, it must
understand all of this.  Given that programmers already have enough
trouble with `clr' instructions that use RMW cycles, making a compiler
understand complicated DMA models would be quite difficult (but again,
I claim, not impossible).  I would be wary of a compiler that tries to
do this (note phrasing :-) ), but I would still like to see it done.
Incidentally, will 68000 (note three 0s) compilers studiously avoid
`clr.l ea' for `ea' volatile?  One would hope so, but putting that into
a C language standard is clearly wrong.

>One (unrelated) deficiency I see in |volatile| involves the generation
>of spurious writes.

Or reads.

>In a perfect world, *p = x would generate one write and no read cycles,
>at least if *p were volatile. ...  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.

You are correct.  Note that, for instance,

	volatile int *word = (int *)FOO;
	int tmp;

	tmp = *word;

must generate two read cycles on an eight-bit peripheral attached to a
16-bit machine.  (A common hardware hack to work around this problem,
incidentally, is to wire [eg] the Z80 SIO chip to A1..An+1 instead of
A0..An; Heurikon does this on the 68010 boards we have in McMob.  All
the device structures are full of pad bytes.)

>I hope that the people who write cross-compilers keep this in mind
>when they add ANSI features ....

This is what X3J11 calls a `quality of implementation issue'.
-- 
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