Xref: utzoo comp.lang.c:9935 comp.arch:4608 Path: utzoo!mnetor!uunet!husc6!mailrus!ames!necntc!ima!johnl From: johnl@ima.ISC.COM (John R. Levine) Newsgroups: comp.lang.c,comp.arch Subject: Re: volatile (in comp.lang.c) Message-ID: <1001@ima.ISC.COM> Date: 4 May 88 16:26:11 GMT References: <20345@pyramid.pyramid.com> <833@mcdsun.UUCP> <9916@tekecs.TEK.COM> <2642@geac.UUCP> <2082@winchester.mips.COM> <2674@geac.UUCP <2686@geac.UUCP> Reply-To: johnl@ima.UUCP (John R. Levine) Followup-To: comp.lang.c Organization: Not much Lines: 43 Summary: very useful, but doesn't belong in the standard >In article <2114@winchester.mips.COM> mash@winchester.UUCP (John Mashey) writes: > [ "volatile" makes it possible to program memory-mapped devices in C, > without having to resort to subterfuges like turning off the optimizer > and hoping the compiler is dumb enough. (I hope this doesn't misrepresent > his argument.) ] Nobody I know has argued that something like "volatile" isn't useful. There's no doubt that it is. The question is whether it belongs in ANSI C, which purports to be a standard for a language for portable programs. The problem is that volatile means many different things to different people. For some people it means a memory-like device register. For others, it means shared memory that might be modified by another process, or memory that might be modified by an interrupt routine or by the operating system. Some optimists even hope that something like this: extern volatile foo; ... foo++; could be used for synchronization of shared memory areas. All of these are useful, and all of them are different. That's why a single keyword in the language doesn't suffice to describe them. You'd have many different implementations giving different semantics to the same syntax, hardly a recipe for portability. Use a compiler-specific extension, or use a #pragma. (I note in passing that for many architectures, if you're addressing device registers you also need some way to tell the compiler to use aligned 16-bit references or some such, which clearly needs to be a #pragma.) I suppose that if the C committee were prepared to decree a standard for the semantics of shared variables, it would then be reasonable to define a keyword to access them. Considering the plethora of shared memory implementations, and the equally large plethora of synchronizing schemes, I doubt any such standard would at this point be acceptable to more than a small minority of users. Until then, though, let's restrict the standard language to things that we know how to make portable. To open another can of worms, this same argument applies to noalias. -- John R. Levine, IECC, PO Box 349, Cambridge MA 02238-0349, +1 617 492 3869 { ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something Rome fell, Babylon fell, Scarsdale will have its turn. -G. B. Shaw