Path: utzoo!attcan!uunet!clyde.concordia.ca!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: NEVERMIND!  (was: Re: A question on volatile accesses)
Message-ID: <14331@smoke.brl.mil>
Date: 5 Nov 90 13:41:23 GMT
References: <2388@lupine.NCD.COM> <1990Nov3.231856.20556@zoo.toronto.edu> <2419@lupine.NCD.COM>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 38

In article <2419@lupine.NCD.COM> rfg@lupine.ncd.com (Ron Guilmette) writes:
>	volatile char *cp;
>		*cp;
>would in fact cause a (byte) fetch from the address pointed to by `cp'.
>Now apparently, the ANSI standard doesn't explicitly require such treatment,

Actually, it does require an access (preferably but not necessarily a byte-
wide one).  See 3.5.3 Constraints.  The implementation must define what
constitutes an access; it is intended that the access be constrained to the
program-specified width whenever possible.

>I found this feature quite useful in certain circumstances (e.g. driving
>I/O chips) in order to be able to code (entirely in C) a simple load
>operation (on say a device register which recognizes the load itself as
>a signal to do something).

Indeed, that was one of the main motivations for the introduction of the
"volatile" type qualifier.  To take a specific example, UNIX device drivers
are almost always coded entirely in C, and on the PDP-11 and similar memory-
mapped I/O architectures, some device registers perform different actions
upon a "read-byte", "read-word", "write-byte", "write-word", "read-modify-
write", or other variations of the memory-bus access cycles involved.
Trying to get the right type of machine code generated while coding the
driver in C was quite tricky, and many hard-to-track-down bugs resulted.
With compilers other than Ritchie's, enabling optimization often would
change this behavior, too.  At least one version of the UNIX Portable C
Compiler (PCC) had a special hack to recognize constructs like
	((struct xxx *)0177450)->zzz
as being potential references to I/O space (device registers) and would
avoid excessive optimization involving such expressions (where the constant
lay within the Unibus I/O address range).  X3J11 decided that this problem
had to be faced squarely, and introduced "volatile" to obviate the need for
such hacks.  However, although it was proposed that conforming
implementations be required to implement the minimum possible access
"width" for volatile-qualified data, and that is the intent of requiring an
implementation definition for it, it was not practical to insist on it in
every implementation; thus, some latitude was allowed implementors in that
regard.