*devaddr = 0 and volatile

[Chris Torek]

>In article <21560 at apple.Apple.COM> desnoyer at Apple.COM (Peter Desnoyers) writes:
>>pet peeve - It is a common thing to have to write a zero to a device
>>register. The obvious code, (* reg_addr) = 0, often results in:
>>  xor reg_addr, reg_addr

I would say not `often' but `sometimes'.

In article <13784 at oberon.USC.EDU>, blarson at skat.usc.edu (Bob Larson) writes:
>... Most 68000 compilers would use the clr instruction, which does have
>the undesired side effect of doing an (ignored) read though.

(True only on the 000; the 010 and 020, and presumably 030, clr does not
read before write.)

>>Unfortunately I don't think specifying bus semantics is within the
>>purview of the ANSI committee ...

This part is true.

>>and volatile is not sufficient to force the desired activity.

>Fortunatly you are wrong, and volitile is sufficient.

Volatile (note the spelling: compilers will not accept the `volitile'
non-keyword) does imply---I will not use the word `guarantee' without
checking the exact wording---that using an XOR or read-before-write-CLR
instruction to clear a volatile location is incorrect.  Consider,
however, a machine which is only word-addressible, on which byte
references compile to shift-and-mask sequences.  I do not know what
the compiler must or even should do if given the following code:

	struct foodev { char c1, c2; };
	f() {
		register volatile struct foodev *p;
		...	/* set up p */
		p->c1 = 0;
	}

The only way to set p->c1=0 is for the compiler to use a sequence like

	load	0(rP),r1
	and	#ff00,r1,r1
	store	r1,0(rP)

I would suggest that the compiler complain about volatile references
that it cannot compile `properly'.
-- 
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