volatiles

[Eddie Wyatt]

> What optimization technique, then, would you suggest in the place of data
> flow analysis with "volatile" to tell the optimizer that a variable that
> COULD change behind its back, actually will do so? The only alternatives
> I can think of are showing the optimizer ALL your source code at once, which
> blows the concept of incremental compilation and modules all to hell (and
> what do you do about variables that can be modified by hardware?), or put
> up with a very conservative, pessimistic "optimizer."  If you have something
> better in mind than the conventional optimizer technology you are bashing,
> tell us about it fella!

   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!

    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.

   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.   

  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



-- 

Eddie Wyatt 				e-mail: edw at ius1.cs.cmu.edu