Path: utzoo!mnetor!uunet!vsi!friedl
From: friedl@vsi.UUCP (Stephen J. Friedl)
Newsgroups: comp.lang.c
Subject: Re: volatile
Message-ID: <511@vsi.UUCP>
Date: 9 Apr 88 01:58:55 GMT
References: <12578@brl-adm.ARPA> <1988Mar25.172355.348@utzoo.uucp> <150@ghostwheel.UUCP>
Organization: V-Systems, Inc. -- Santa Ana, CA
Lines: 29
Summary: Source-level optimizations only?  Huh?

In article <150@ghostwheel.UUCP>, ned@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@unh's brother"
friedl@vsi.com  {backbones}!vsi.com!friedl  attmail!vsi!friedl