Path: utzoo!mnetor!uunet!ncc!alberta!att-ih!ihnp4!ihlpf!nevin1 From: nevin1@ihlpf.ATT.COM (00704a-Liber) Newsgroups: comp.lang.c Subject: Re: volatiles Message-ID: <4437@ihlpf.ATT.COM> Date: 15 Apr 88 22:08:10 GMT References: <1394@pt.cs.cmu.edu> <1530@dataio.Data-IO.COM> <1412@pt.cs.cmu.edu> <2584@ttrdc.UUCP> <1414@pt.cs.cmu.edu> Reply-To: nevin1@ihlpf.UUCP (00704a-Liber,N.J.) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 61 In article <1414@pt.cs.cmu.edu> edw@IUS1.CS.CMU.EDU (Eddie Wyatt) writes: > One could argument why do data flow at all when, in my opinion, >the gains are minimum (in the range of 20% to 30% speed up of code >and reduction of code size) and payment high (incorrect code or an >obscure modification to the underlying language). I'd rather my compiler >be pessimistic than wrong! But the compiler isn't wrong, the code is! If data flow optimization is allowed, then programs have to be written with the single-thread notion in mind. Since 99% of execution of programs is single-thread, this is not an unreasonable assumption to make. Since this assumption is not always true, however, there needs to be a way to get around it. Volatile is the proposed way around it (although personally, I don't think the solution is good enough). > Another option for you is to consider developing an entire new >language with multi-tasking support. Design it in such way that it >is easy to optimize, and is general enough to describe external events >such as hardware as a special task. Do you intend to rewrite all of Unix and all the C applications currently in use in your new language? And are you willing to train all the people who are going to use this new language? And what do we do during the three or four years that it is going to take to fully develop this language? Writing an entirely new language is not a viable solution for the short term. > Another option for you is to have the user target the variables >for optimization instead of taking the attitude that its up to the user >to target those variable that are not be optimized. Again my attitude >here is that at least the user has to go out of his way to screw >himself over. This may be true, but 99% of the variables in a program can legally be optimized in this fashion. This is like saying that all variables which are going to have their address taken should have the keyword 'noregister' in front of it. All this does is lead to a very verbose language. > My real fear about the addition of volatile is that a programs compiled >without data flow optimization will run perfectly fine. Porting it >to a machine with data flow optimizing compiler will break it. Now who >is to blame? I think in those cases the optimizer will become useless >and the only thing you will accomplish is giving a bunch of people >large head aches Then just declare all your variables as volatile! Just using a different compiler or a different implementation of libraries can break code! The data flow optimization is not unreasonable, since you ought to know what variables in a program can change by some mechanism other than normal execution anyway. If you don't know this I don't see how it is possible to write a non-trivial program. Did you ever assume that you could save the result of strlen() for a string you could never change? Without assuming single thread operation, this is a bad assumption and should not be used (and we would all have very inefficient programs). Non-volatility always has to be assumed to some degree. -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_