*devaddr = 0 and volatile

[Rick Schubert]

I probably shouldn't do this, since getting involved in such discussions
usually causes more grief than satisfaction, but I just attended a
motivational talk encouraging risk-taking, so here goes.

In article <14832 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
::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

:::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.

I won't make any guarantees either, but I believe that using an XOR is NOT
incorrect as far as the dpANS is concerned (although it would be a poor
quality of implementation).  Quoting from the May 13, 1988 Draft (page 62,
lines 10-11):
	What constitutes an access to an object that has volatile-qualified
	type is implementation-defined.
I don't think we (X3J11) changed this at the September, 1988 meeting.  My
recollection from past discussions on this is that we didn't think it would
be feasible to specify precisely how many times and in what ways a volatile
object should be accessed.  It's a very tricky area because volatile deals
with inherently machine-dependent constructs (e.g. device registers), whereas
the Standard is trying to specify portable (or machine-independent) behavior.
Since `access' depends on such things as the instruction set, object size,
and alignment, it is pretty much outside the domain of X3J11 to make such a
specification.

Now, in a practical sense, if a machine has a device register that, in some
situation needs to have the value 0 stored in it, and if reading its value
(1 or more times) before writing a 0 would cause undesirable behavior, then
there must be some instruction (or instruction sequence) to store a 0
without a read (or multiple writes).  If the compiler writer does not
generate such an instruction, but instead uses (for example) XOR because
XOR is faster, then the compiler writer made a poor (to put it mildly)
choice, but I don't think you could take that person before an official
X3J11 court and get a conviction.  XOR still can be used for non-volatile
objects, so your benchmarks won't have to suffer.

: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;
:	}
: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

In article <23706 at amdcad.AMD.COM> tim at crackle.amd.com (Tim Olson) writes:
:I was speaking to Richard Relph about this subject, and he brought up
:the problem of unaligned accesses through a pointer to a volatile object
:which is larger than a char, but is not properly aligned [what a
:mouthful!].  These also require multiple accesses to be performed
:"correctly."  What should be done here?
:	-- Tim Olson
:	Advanced Micro Devices

I think these 2 examples demonstrate why X3J11 didn't try to specify the
"correct"  or "proper" behavior in such circumstances.  I also don't think that
either situation would come up in practice.  Remember, `volatile' is primarily
for accessing the hardware in a hardware-specific way;
the hardware designers wouldn't [be so stupid as to] design an object that
must be accessed in a specific way (e.g. a byte that must be accessed without
touching the adjacent byte) without an instruction (or instruction sequence)
to access the object in that way.

Disclaimer 1: None of the above is an official X3J11 position.
Disclaimer 2: Notice the "I believe"s and "I think"s, and be gentle if I am
              wrong.
Disclaimer 3: Sorry if I got some of the secondary attributions wrong;  I had
              trouble following some of chains of "In article ... ... writes:"
Disclaimer 4: Spelling errors inside of quoted articles are not my fault;
              spelling errors outside of quoted articles are "spell"s fault.

-- Rick Schubert (rns at se-sd.sandiego.NCR.COM)