Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!scs From: scs@athena.mit.edu (Steve Summit) Newsgroups: comp.lang.c Subject: Re: volatile: a summary Message-ID: <5807@bloom-beacon.MIT.EDU> Date: 17 Jun 88 02:41:56 GMT References: <11837@mimsy.UUCP> <3811@pasteur.Berkeley.Edu> <580@wsccs.UUCP> <700@fxgrp.UUCP> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: scs@adam.pika.mit.edu (Steve Summit) Lines: 59 In article <11837@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > A perfect compiler would know as much as all its programmers combined, > and could use whatever rules those programmers would use to detect > `real volatility'. In article <700@fxgrp.UUCP> ljz%fx.com@ames.arc.nasa.gov (Lloyd Zusman) writes: >But what if... as have many others. You people need to understand that Chris is being extremely theoretical, to the point of pedagogy (not meant pejoratively), here. It took me several readings of several of his articles (which I was quite willing to do, because Chris is a trustworthy sort) to realize that he does, as usual, know what he is talking about. Chris _i_s _c_o_r_r_e_c_t when he says that "a perfect compiler would not need volatile" but he is _n_o_t saying that such a compiler would be reasonable. He has stated several times that an explicit "volatile" keyword is an eminently reasonable pragmatic solution to a theoretically difficult problem, a position with which I certainly agree. Every article that suggests yet another funky architectural scenario in which it would be next-to-impossible for the compiler to reasonably "figure out" which variables should be volatile overlooks one of the following: 1. There are ways other than a "volatile" keyword to tell a compiler which memory locations are volatile: a configuration file, for instance, not only solves the frequently suggested cross-compilation situations, but is also a better way of handling things like device registers: if location 0xABCD is a keyboard input buffer, it should really be volatile whether or not the programmer remembers to use (or knows about) the "volatile" keyword. 2. If there are ambiguous or computationally undecidable cases, the compiler can always err conservatively by treating questionable variables as volatile (i.e. not optimizing away memory references). Finally, the fact that (2) leads to unacceptable compromises like "all system call return values are volatile," and the fact that other cases are computationally horrendous, is why the "volatile" keyword is useful. Please don't post more "proofs" or counterexamples; when you triumphantly say "So there! No compiler can reasonably get this one right without volatile!" Chris is only going to say "Well, you're right; it could theoretically get it right, but not reasonably, so that's why we'll stick the `volatile' qualifier in." My $0.02 worth: a command-line flag or pragma to effectively make everything volatile would be very nice so that old programs can be "correctly" (if inefficiently) compiled by the newer compilers that make the kinds of optimizations that "volatile" is intended to inhibit. Steve Summit scs@adam.pika.mit.edu