Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!rbbb.Eng.Sun.COM!chased
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.arch
Subject: Re: What the compiler won't do you for you
Message-ID: <8787@exodus.Eng.Sun.COM>
Date: 28 Feb 91 00:50:48 GMT
References: <8658@exodus.Eng.Sun.COM> <6521:Feb2621:31:1491@kramden.acf.nyu.edu> <8728@exodus.Eng.Sun.COM> <13578:Feb2705:46:4391@kramden.acf.nyu.edu>
Sender: news@exodus.Eng.Sun.COM
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 66

brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>In the article you responded to, David, I proposed a language construct
>to let the compiler choose one of several sections of code. It is f'ing
>obvious that this makes the program ``portable for speed.'' It is f'ing
>obvious that I proposed the construct *exactly* because I am worried
>about efficiency, and because I am trying to *reduce* the work of the
>compiler writer and programmer in making code efficient. The only way
>now to make portable code efficient is to spend years communicating with
>language designers and chip writers. I want to reduce that time.

Dan, you're missing the forest for the trees, several times over.
Even if the general idea that you propose were worthwhile, your scheme
for accessing special-purpose assembly language instructions from
portable code is too complicated.  It is gratuitously difficult for
both the compiler writer and the programmer.  Compare:

Dan's method:

compiler writer writes recognizer for special code sequences.
compiler writer documents these code sequences.
programmer reads the code sequences.
programmer writes these code sequences.

Simpler method:

compiler writer writes library of inlineable code.
compiler writer documents names of routines that are in this library.
programmer uses those names.
if you insist, compiler writer writes portable versions of these
   subroutines, though programmer would have had to do it anyway in
   your method (working from documentation).

No need to recognize complicated code sequences, and easier to use.
The inliner sucks in the code automagically.  Writing the portable
version is no harder than figuring out what pattern is recognized, but
you don't have to write a pattern recognizer, OR impose restrictions
on what transformations might be performed by the optimizer now or in
the future that might complicate pattern recognition (yes,
straight-line code can get oddly mutilated).  No need to promise that
in the future, a special chunk of code will result in the use of a
special instruction.

Now, no doubt in your next twisted missive you will claim that is
exactly what you proposed, since, of course, a procedure call is a
special case of a code sequence.  This behavior is already supported
by existing compilers -- there's several people who write inlineable
routines for Fortran -- so if this is what you meant, then you are
ignorant of the state of current tools.  Since that cannot possibly be
the case, I conclude that this is not what you meant.

In addition, as I said before, there is ample evidence that time is
better spent doing a good job of optimizing code in a general way.  If
it paid to do the things that you propose, it would have showed up in
compiler tuning.  People do look at the code that is generated, and
try to come up with ways to make it better.  Somehow, nothing like
your idea even made it onto the list, let alone near the top.

Perhaps you have an exaggerated opinion of your intelligence and the
importance of your problems.  Just a guess.  By the way, is
abbreviating "fucking" into "f'ing" consider politeness on the net?
Thanks for being so considerate.

Your pal,

David Chase
Sun