Path: utzoo!attcan!uunet!husc6!purdue!umd5!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.lang.c Subject: Re: volatile: a summary Message-ID: <11884@mimsy.UUCP> Date: 9 Jun 88 15:18:05 GMT References: <11837@mimsy.UUCP> <3811@pasteur.Berkeley.Edu> <11848@mimsy.UUCP> <705@garth.UUCP> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 86 In article <705@garth.UUCP> smryan@garth.UUCP (Steven Ryan) writes: >This is getting ridiculous. I propose a formal schism between the AI church >that believes computers can do anything and a pragmatic church that believes >computers are stupid. (Apologies for the harsh tone, but it is obvious that those who are objecting to my reasoning have not thought about implmentations and their difficulties. I thought a bit of chastisement in order. :-) ) I am guessing that this is in response to my suggestion that whenever a programmer can discover that *(int *)0xf0 is not volatile, but *(int *) 0xff4 is, by reading a manual, a hypothetical perfect compiler can do the same by reading `(the electronic version of) the manual'. Those who believe that this implies `computers can do anything' have not exercised their brain cells about it. Why must the compiler's version of the manual be the same as the programmer's, or even be exclusively in some natural language? The compiler's electronic version of the manual might even read volatile 0xff0..0xf9f In this case, even though the word `volatile' appears *somewhere*, it is nowhere in the C source, and hence the language proper has no volatile keyword. For those who will claim that this is mere trickery, again, you have not thought hard enough about the issue. Instead of `volatile 0xff0..0xf9f' the manual might instead say `ram 0x0..0xeff; ram 0x4000..0xbfffffff'. Instead of saying what *is* volatile, this says what *cannot* *be* volatile. And if the electronic manual does not exist, or if my hypothetical perfect compiler does not exist, as it does not, or even if it *cannot* exist, what then? Is the volatile keyword necessary? No. Consider the IBM PC. (This since I was flamed for using Unix compilers as an example.) In the following (toy) large model program, which assignments might be (not *are*, just *might* *be*) volatile? #define DISPLAY 0xc000000 /* or whatever */ main() { int i, *p1, *p2; p1 = &i; /* 1 */ p2 = (int *)DISPLAY; /* 2 */ *p1 = 3; /* 3 */ *p2 = 'k'; /* 4 */ for (; i < 100; i++) { if (rand()) p1 = p2; /* 5 */ *p1 = 0; /* 6 */ } exit(0); } Even without knowing whether 0xc000000 is display RAM, I can accurately predict that assignments number 1, 2, 3, and 5 are *not* into volatile memory; only assignments 4 and 6 can possibly write volatile locations. Whether 4 and 6 actually do write volatile locations (and if I got the display address right, they do not) is not important: all the other assignments do not, and may therefore be optimised. If you claim that this analysis cannot be extended beyond toy programs, then again you have not used your brain. It not only *can* *be* done, it *has* *been* done. You can buy a C compiler today% that does cross-module optimisation. That compiler may not run on an IBM PC. Well, I never said it would be *easy*. And that compiler may produce suboptimal code for assignments that *could* *be* volatile but (as it happens) are not. Well, I said that too. If you believe this argument means I think the volatile keyword is bad, go back and read <11837@mimsy.UUCP>. All I have said is that the keyword is not necessary, not even for optimisation. ----- % One such compiler is the one MIPS uses. I know it does final code generation at link time. Whether it tries to do alias detection at this time I cannot say; but ruling out volatility is a special case of alias detection (`does this pointer alias an unknown variable'). Given that their compiler has the `volatile' keyword, I imagine it does not bother. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris