Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!utah-cs!shebs
From: shebs@utah-cs.UUCP (Stanley Shebs)
Newsgroups: comp.arch
Subject: Re: Benchmarking ...[really Compiler flames]
Message-ID: <4628@utah-cs.UUCP>
Date: Fri, 5-Jun-87 11:15:14 EDT
Article-I.D.: utah-cs.4628
Posted: Fri Jun  5 11:15:14 1987
Date-Received: Tue, 9-Jun-87 07:02:06 EDT
References: <410@winchester.UUCP> <3490003@wdl1.UUCP> <7261@amdahl.amdahl.com> <787@ttidca.TTI.COM>
Reply-To: shebs@utah-cs.UUCP (Stanley Shebs)
Organization: PASS Research Group
Lines: 54
Keywords: compiler design, compiler designers

In article <787@ttidca.TTI.COM> sorgatz@ttidcb.UUCP (Erik Sorgatz - Avatar) writes:

> This is the central point: most compilers are dumb. They appear to have been
>written by someone scarcely familar with the hardware environment. The classic
>examples of 'jump-to-the-next-instruction' or 'save-all-registers/do-something-
>non register-related/restore-all-registers' are the biggest wastes of MIPS
>although some optimizers will nail these => 50% of the time.

Only the dumbest of compilers will miss these.  Jumps to the next instruction
and extraneous stack ops can even be handled using 'sed' on the assembly
language output (I've done it).

>Consider this to be my contribution: Wakeup compiler experts! Read the !@#$%^&
>chip spec! Don't assume that your 'meta-pass-intermediate code generators
>are going to produce efficient code; they dont!

\begin{flame}
I can never finish reading the chip spec because I get sick and have to go
home halfway through!  So-called features get included because some hardware
engineers figure that *their* assembly-language programs are representative
of programming as a whole, and so they put in perverted instructions/timings/
details.  Or the hardware has some "optimization" that makes it totally
impossible for a compiler writer to figure the performance without actually
running the code to see what happens!
\end{flame}

There are very good compilers in the world that do take advantages of
specific machine features.  However, they tend to be 1-2 orders of magnitude
more expensive than your public-domain Pascals and BSD C compilers, and so
most places don't have them.  Good code generation can be expected to take
many person-years of effort, per machine per language.  The whole
motivation for various automated techniques for building code generators
is to bring this cost down.  Unfortunately, the techniques are only as
good as our models of hardware behavior, and the days are long gone when
program performance could be predicted by adding together the timings
of each instruction.  When the accurate machine simulator is a 40,000
line C program, it's going to be very very hard for automated code generator
constructors (or humans, for that matter) to figure out where the good
performance *really* is, as opposed to where the hardware designers say
it is!

Likewise, the motivation for intermediate languages is that for M languages
and N machines, use of an intermediate language means M+N pieces of compiler
instead of MN whole compilers.  If we could all standardize on one language
or one machine, the problem would pretty much go away, but there's not much
chance of that.

The compiler experts are already awake, but there are limits to how many
hardware-imposed rings they can jump through...

>-Avatar-> (aka: Erik K. Sorgatz) KB6LUY

							stan shebs
							shebs@cs.utah.edu