Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!pyramid!prls!philabs!micomvax!ray From: ray@micomvax.UUCP (Ray Dunn) Newsgroups: comp.lang.c Subject: Re: const, volatile, etc Message-ID: <1526@micomvax.UUCP> Date: 9 Dec 88 23:04:41 GMT References: <674@quintus.UUCP> <117@halcdc.UUCP> <468@auspex.UUCP> <9016@smoke.BRL.MIL> <10919@ulysses.homer.nj.att.com> <9033@smoke.BRL.MIL> <319@aber-cs.UUCP> Reply-To: ray@micomvax.UUCP (Ray Dunn) Distribution: eunet,world Organization: Philips Electronics Ltd. (TDS - Montreal) St. Laurent QC, Canada Lines: 69 In article <319@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > [long argument against "volatile] >First of all, in a sense, volatile and register exclude each other; in >traditional C all variables are volatile save for those declared to be >register (and this explains why there is a restriction on &...). Unfortunately, the whole foundation of your argument is incorrect. All variables in tradional 'C' are *non-volatile*. Nowhere is there any guarantee that each and every variable reference made in a 'C' source will translate to a memory reference in the run code. That is what "volatile" gives you. > [continued long argument totally confusing "volatile" with > *performance* issues and the use of "register"] There is no relationship between "volatile" and "register", except that conceptually, "volatile" variables can *NOT* be of type register and cannot be arbitrarily *kept* in a register in the compiled code. In addition to the performance issue, "register" implies the exact opposite of "volatile". >Arguments for volatile, as opposed to register, are essentially: > > [1] you cannot trust programmers to be competent and understand > what they are writing, or at least not enough to place appropriate > register declarations; in that case an automatic optimizer will > possibly improve things, even if it does a purely static analysis. Volatile is not *just* needed as an adjunct to optimizing compilers. Volatile is needed in *all* cases when the programmer wishes to convey to the compiler that a variable has environmental constraints normally not the concern of the compiler. It is in fact only luck that most traditional compilers handle machine specific volatile variables correctly when no optimization is called for, and without the use of the "volatile" keyword. >As to point [1], unfortunately you need damn competent programmers that >understand a lot of the subtleties of their program to place volatile >where it is needed, and only there, otherwise they will be inclined, >for safety, to declare everything in sight to be volatile... and produce "vapourware" I presume.... (:-) The argument that programmers can be expected to be competent enough to design the algorithms of the program, and analyse their code sufficiently to be able to duplicate the effects of a good optimizizing pass, but that somehow some esoteric higher level of understanding is required to be able to place "volatile" appropriately, I find most unconvincing. If the programmer does not understand which variables are referencing "locations" which can side effect or be side effected by other software or hardware, then should (s)he be let loose in that environment? Classical examples of the need for "volatile" are when handling memory mapped I/O, or inter-process signals. In these cases, amongst many others, we need to ensure that the compiler is not treating an I/O write or a signal update as an intermediate value that does not *yet* need to be written into the actual memory location. Does the traditional definition of 'C' allow the programmer to be sure that the compiler is treating these cases correctly? Nope! -- Ray Dunn. | UUCP: ..!philabs!micomvax!ray Philips Electronics Ltd. | TEL : (514) 744-8200 Ext: 2347 600 Dr Frederik Philips Blvd | FAX : (514) 744-6455 St Laurent. Quebec. H4M 2S9 | TLX : 05-824090