volatile (in comp.lang.c)

[John Mashey]

In article <2674 at geac.UUCP> daveb at geac.UUCP (David Collier-Brown) writes:

>In article <2642 at geac.UUCP> daveb at geac.UUCP (David Collier-Brown) writes:
>|     It is interesting to note that there have not been, to date,
>| **any** other discussion of the necessity of "volatile" et all, only
>| of their desirability in a given language, taking their necessity as
>| **a given**.

>In article <2082 at winchester.mips.COM> mash at winchester.UUCP (John Mashey) writes:
>| This is an assertion of non-fact.  There was such a discussion that
>| ran for about a week, a month or so ago, at least in comp.lang.c.
>| People gave examples of potential usage; some of us who have it and use
>| it said so; I observed that both of our kernels had about 200
>| instances of volatile, and we'd miss it a lot if it weren't there.

> Sorry John, that's not a discussion of the necessity for such a
>facility.  (Yes, I read your article when it was published).
>  That your compiler-wriers believed that such was necessary **is**
>germane, and I'll happily agree that, if found necessary by the
>compiler-writers, one would be a little foolish to not use it (:-)).

It wasn't our compiler-writers, it was us (the OS group) who thought we
needed it.

>  I reiterate: the question of the necessity of certain information
>for optimization purposes is:
>	1) in part architectural,
>	2) in part a question of compiler technology, and
>	3) open.

>  Specifically:
>	1) what architectures currently use asynchronously-changing
>memory locations for program notification of events? DEC Vax,
>various CDC boxes, MIPS(tm),...
>	2) what other programmer-visible alternatives are there?
>Interrupts, event queues, (Hoare) monitors... 

As I thought I'd mentioned before, the most immediate cause of wanting
volatile has nothing to do with computer architecture in the sense of
1), or OS theory/practice in the sense of 2), but the very simple,
practical reason, that in an open systems design, using a standard
bus, and buying off-the-shelf controllers, you will discover that
many such controllers, otherwise desirable, use memory as
a communication mechanism.  You get a choice:
	a) Add volatile to C, and be able to optimize your drivers
	with minimum performance loss, thus maintaining the ability to
	use C rather than assembler without irritating performance lossage.
	You also get to port existing drivers fairly easily.
	OR
	b) Don't optimize your drivers very much.
	OR
	c) Eliminate many potential peripheral controllers, or at best,
	have to completely redo drivers you get from elsewhere.
	OR
	d) Build all your own peripheral controllers.
Of these options, most people do b), because c) and d) aren't practical
for many organizations; a) is clearly more pleasant, an much more in tune
with the philosophy in UNIX that using C shouldn't cause you a big
performance hit, and that C should be able to describe devices and
otehr interfaces not under the software architect's control.

Does that address the question: volatile matches the reality of what's
out there, not what might be possible otherwise.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash at mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086