Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!mips!apple!uokmax!munnari.oz.au!cluster!steve
From: steve@cs.su.oz (Stephen Russell)
Newsgroups: comp.lang.misc
Subject: Re: 'register' variables and other goodies (was Re: Common subexpression optimization)
Message-ID: <723@cluster.cs.su.oz>
Date: 15 Feb 90 13:58:36 GMT
References: <1624@aber-cs.UUCP> <1990Feb12.172948.17784@jarvis.csri.toronto.edu> <PCG.90Feb13161349@rupert.cs.aber.ac.uk>
Sender: news@cluster.cs.su.oz
Reply-To: steve@cluster.cs.su.oz (Stephen Russell)
Organization: Basser Dept of Computer Science, University of Sydney, Australia
Lines: 50

In article <PCG.90Feb13161349@rupert.cs.aber.ac.uk> pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) writes:

>I tend to agree in principle. In practice, things are less clear
>cut. [...] The beauty of things like 'register' is that they are
>absolutely safe and effective, without any analysis whatsoever.
>I think that rather than sticking complex, often unreliable and
>ineffective optimizers in the bowels of code generators, ...

Complex, probably, though this depends on the target architecture and
the ambition of the compiler writers. Simple optimisers can be very
effective (eg, Powell's Modula-2 compiler's register allocation
strategy).

Unreliable, sometimes.

Ineffective, depends. There have been some very effective optimisers
around (eg, Bliss, DEC M2, MIPSCo).

A typical optimiser does much more than just register allocation.  It
may even be essential when there is a mismatch between the source and
target architectures. The match for C and the PDP-11 was very good, but
this doesn't guarantee that C will match all other architectures as
well.  Without a good optimiser, improving the match may require lots
of hand rewriting when code is ported. A well-written code generator
will do most of this rewriting automatically, and perform optimisations
that cannot be expressed (or only in an ugly manner) in the source
language.

>... the following topics should be explored:

[list of topics deleted, except for ...]

>5) programmer's assistants that do a thorough analysis of the source code;
>6) programmer's assistants that help make transformations of the source code;

What would you call an effective "programmer's assistant" that does a
thorough analysis of code (the level is mostly irrelevant) and makes
optimising (you don't want _worse_ code, right?) transformations? I'd
call it an optimiser.

>I am aware of some work in the literature about these points
>(Alpeh, Euclid, lint, ....), but it is pitifully small compared
>to the vast effort expended on what by comparison is an unsafe,
>inefficient shortcut, "optimizers"

I don't see how arguing in favour of safer HLL's is an argument against
aggressive code generators. In fact, I would have thought that further
movement away from programming the bare metal increases the need for
better optimisers to bridge the gap, particularly when RISC
architectures are also increasing the gap.