volatiles

[00704a-Liber]

In article <1414 at pt.cs.cmu.edu> edw at 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."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah