Re: Compiler back-ends [Q] (David Keppel)
Wed, 25 Oct 1995 15:59:46 GMT

          From comp.compilers

Related articles
Compiler back-ends [Q] (1995-10-21)
Re: Compiler back-ends [Q] (1995-10-23)
Re: Compiler back-ends [Q] (1995-10-25)
Re: Compiler back-ends [Q] (1995-10-27)
Re: Compiler back-ends [Q] (1995-10-29)
Re: Compiler back-ends [Q] (1995-11-03)
Re: Compiler back-ends [Q] (Sebastian Schmidt) (1995-11-03)
Re: Compiler back-ends [Q] (1995-11-03)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (David Keppel)
Keywords: code
Organization: Computer Science & Engineering, U. of Washington, Seattle
References: 95-10-099 95-10-114
Date: Wed, 25 Oct 1995 15:59:46 GMT

> (Ben Sloman) writes:
>> `the back-ends of most production compilers are generated automatically'
>> True or false? On what grounds (examples/references appreciated)?
>> ...
>> [I'll eat my hat if it's true. -John]

In 95-10-114 (Cliff Click) writes:
>[`lcc', `gcc', TI compilers, Motorola compilers.]

Not to forget the Greenhills compilers, which use a proprietary machine
description and have been ported to a variety of systems including x86
and KSR1.

FWIW (though this hardly counts as ``most''), I've heard a rumor that
SunSoft has, for several years now, tuned their schedulers using an
automated system rather like Henry Baker's ``Precise Scheduling Without
a Machine Model''. According to rumor, the scheduler executes a suite
of benchmarks, trying each benchmark a variety of scheduling options
and tuning to those options that provide the best measured performance.
They iterate through this several times across a variety of machines,
eventually selecting the option that provides the best overall speedups
without substantially hurting code quality on other Sun platforms. At
least that's the rumor I heard.

(Fortunately, John's hat is made of bread and the strings of Pasta.)

;-D oN ( The back-ends justify the means ) Pardo

Post a followup to this message

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