Path: utzoo!attcan!uunet!husc6!bloom-beacon!athena.mit.edu!peter
From: peter@athena.mit.edu (Peter J Desnoyers)
Newsgroups: comp.lang.c
Subject: Re: volatile (in comp.lang.c)
Message-ID: <5367@bloom-beacon.MIT.EDU>
Date: 16 May 88 03:19:42 GMT
References: <2642@geac.UUCP> <225800029@uxe.cso.uiuc.edu> <4727@ihlpf.ATT.COM>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: peter@athena.mit.edu (Peter J Desnoyers)
Organization: Massachusetts Institute of Technology
Lines: 27

The debate over |volatile| seems to focus on one point: if this
keyword is only necessary for non-portable code, why does it have to
be part of the language?

I think this point has been made before, but I will make it again.
Non-portable language constructs (e.g. pragmas) are specific to a
compiler. Memory-mapped IO and other such things which require
volatile are specific to a target machine. Most software in this world
is written on a system different from that on which it is run. (You
know, the stuff that runs microwave ovens, telephone systems, and just
about everything else.)

Now, if I developed the code for my network box (for example) on the
department VAX, using vendor A's compiler and their pragmas to massage
the IO chips, and I want to switch to using workstations that may not
be supported by vendor A, you would say tough. Since my target
architecture is not portable, anything associated with it can't be
portable, either. Only Unix applications should be portable, anyway.

Whereas, if |volatile| is added to the language, then I can compile my
code on any cross-compiler for my target machine, download it to my
ICE, and go merrily on my way. Since the semantics of |volatile| will
have to be implemented in any reasonable compiler, doesn't |volatile|
seem to make much more sense?

				Peter Desnoyers
				peter@athena.mit.edu