Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!husc6!purdue!umd5!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.lang.c Subject: Re: Volatile is stupid Keywords: Compilers don't know all! Message-ID: <12150@mimsy.UUCP> Date: 26 Jun 88 15:08:11 GMT References: <11837@mimsy.UUCP> <225800035@uxe.cso.uiuc.edu> <5800@aw.sei.cmu.edu> <314@accelerator.eng.ohio-state.edu> Distribution: na Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 64 >In article <12056@mimsy.UUCP> I suggested that a worst case (not necessarily the only one) is where a pointer is read in at runtime: >>The key point here is that there is no algorithmic way to determine >>volatility in this worst case---so any competent programmer must >>assume that, if there are any volatile addresses, this code may refer >>to one. The programmer's only other option is to decree that the >>program must never read an address that *is* volatile. A programmer >>who makes such a decree is certain to be surprised by a user. ... In article <314@accelerator.eng.ohio-state.edu> rob@kaa.eng.ohio-state.edu (Rob Carriere) writes: >What if the pointer ip is the output of another program, known to >produce only non-volatile pointers? Then the program will work fine for five years, and someone will install it in an airplane controller, then someone else will manually `correct' something, and your program will crash, along with the airplane. This is what correctness checking is all about. >I know, the compiler.... That compiler is going to be rather sizable! Yes, it will probably be enormous. I doubt that I would want to use it until computers are some orders of magnitude faster than they are today. >>`But wait!' you say. `Even a very fancy optimising ``compiler'' >>(linker) is going to miss *some* things. Why, we can use some fancy >>mathematics to prove that it cannot catch everything.' >> >>That is so. But how often will this occur in practise? Today, >>probably all the time; but tomorrow? Five years from now? Fifty? >1) You started out by saying ``volatile'' is *useful* not *necessary*. > You have just admitted the fallacy of your own argument :-) Not really: I believe it is not necessary to get perfect optimisation: enough that the difference is hard to notice is enough. Any more is unnecessary. (In a way, *all* optimisation is unnecessary. Useful though. :-) ) >3) All this discussing boils down to: we have to tell the compiler > about the volitile things in life at *some* time, either when it's > born (your point of view), (or at compile time, just before compiling the code) > or when it gobbles up my program (us > volatile types). Well, *I* have to know as well (or I can't write the > code correctly) => from a readability point of view that means that > that information should be IN THE CODE. Now, that's easy to achieve, > just add a keyword, say ``volatile''... And if you have been reading all of my articles, I happen to agree. I *like* the volatile keyword! But I also like automatic volatility detection. A compiler that says "foo.c", line 1234: warning: *p may be volatile, but is not declared so and then goes on to produce an incorrect program is *much* better than one that simply produces the incorrect program. And I think I shall say no more on that, at least for a few months. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris