volatile

[Stephen J. Friedl]

In article <150 at ghostwheel.UUCP>, ned at ghostwheel.UUCP (Ned Nowotny) writes:
> Optimizers should not do optimazations which can be expressed in the
> source language itself.  However, if they recognize a possibly
> poor construct, they should warn the programmer.

     Huh?  I think this is terribly naive.  First, a construct
"source-optimized" for one machine may turn out to be
counterproductive on another machine.  The best way to do
pre/post ++ and -- probably varies from one architecture to
another, and surely there are a host of other examples (array
referencing, function calls, etc.)

     Second, how far should this be carried?  Require traversing
a chunk of data with pointers rather than with an array index?
Require inline |asm| code?  Mental data-flow analysis?

     Finally, and most importantly, isn't one major goal of a
high-level language to insulate us from those details?  Defining
"poor construct" solely from the view of the compiler or CPU
rather than from the view of a human is contrary to this notion;
surely I am not the only one who has sometimes sacrificed
"efficiency" in favor of other issues (readability, portability)
when it was appropriate.  Having a smart translation system helps
me get the best of both worlds.

     Steve
-- 
Steve Friedl   V-Systems, Inc.   "Yes, I'm jeff at unh's brother"
friedl at vsi.com  {backbones}!vsi.com!friedl  attmail!vsi!friedl