Re: End of optimization...

Fergus Henderson <>
4 Aug 2003 00:15:27 -0400

          From comp.compilers

Related articles
[6 earlier articles]
Re: End of optimization... (Walter Banks) (2003-07-23)
Re: End of optimization... (2003-07-25)
Re: End of optimization... (Fergus Henderson) (2003-07-25)
Re: End of optimization... (2003-07-31)
Re: End of optimization... ( (2003-08-04)
Re: End of optimization... (Alan Lehotsky) (2003-08-04)
Re: End of optimization... (Fergus Henderson) (2003-08-04)
Re: End of optimization... (2003-08-10)
Re: End of optimization... (2003-08-10)
| List of all articles for this month |

From: Fergus Henderson <>
Newsgroups: comp.compilers
Date: 4 Aug 2003 00:15:27 -0400
Organization: The University of Melbourne
References: 03-07-026 03-07-068 03-07-151 03-07-179 03-07-200
Keywords: optimize
Posted-Date: 04 Aug 2003 00:15:27 EDT (Robert L. Knighten) writes:

> writes:
>> >Compilers only make sense for platforms - i.e. for some kind of
>> >generally programmable hardware for which a moderate number of
>> >applications will be developed.
>Fergus Henderson <> writes:
>> I think this ignores technology improvements which mean that it is
>> possible to cheaply generate a somewhat optimizing compiler for
>> a new chip, by just giving a machine description for the new chip.
>Really? I've not been designing compilers for a dozen years now, but I
>haven't seen any evidence that it has really gotten particularly easier. And
>it certainly wasn't cheap back then, and the result was not even "somewhat
>optimizing". Retargetable compilers fit very closely to the UNCOL myth our
>moderator just exposed.

I'm not talking about implementing a compiler from scratch, just about
adding a new back-end to an existing compiler. For lcc, for example,
adding a new back-end requires only about 1000-1500 lines of code.
This is not necessarily easy, but then neither is writing assembly
language code by hand.

The resulting compiler will be "somewhat" optimizing in the sense that
you can reuse the existing implementation's target-independent
optimizations such as inlining, constant propagation, dead code
elimination, etc. The lcc compiler is not a particular good example
here, since it doesn't do much of those kind of optimizations. But
there's no technical obstacle to fixing that.

There are also other (probably better) examples out there. For
instance, see, which advertises a tool that will take
a machine description and produce not just a compiler, but also an
assembler, disassembler, linker, simulator, debugger, etc. They claim
that their compiler does a variety of optimizations (see the long list

The choice this approach offers is either writing your whole
application in assembler by hand, or writing a fairly small machine
description and then writing most of your application in C, with just
the innermost loops hand-coded. For all but very small applications,
if you hand-code it all in assembler then your total source code size,
development effort, and time-to-market will all be larger, even though
you don't have to write a machine description, because assembler is a
considerably lower-level language than C. Furthermore, it will be
harder to reuse the results of this effort for your next project.
Fergus Henderson <> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <> | -- the last words of T. S. Garp.

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.