Re: Writing fast compilers...

[From comp.arch -John]


On 13 Aug 91 13:46:36 GMT, preston@helena.rice.edu (Preston Briggs) said:


preston> davidsen@crdos1.crd.ge.com (bill davidsen) writes:


davidsen> Optimizing compilers are not going to produce as much
davidsen> improvement on well written code as they will on student first
davidsen> attempts, because the common subexpressions have be done in
davidsen> source, the invariant stuff is out of loops, the loops are
davidsen> unrolled, the register type has been used here and there...
davidsen> all by a one pass code generator called a programmer.


This is one of my favorite arguments, and its architectural aspect is
that I agree with you (and Hoare as reported by Preston Briggs later on)
that for conventional languages the architectural boundary between the
effort spent by the programmer and that spent by the compiler should be
such that the compiler need not do extensive program
rewriting/reorganization...


preston> I'm going to poke a little at this... IMHO, traditional
preston> optimizations (say, up to vectorization) are mostly useful for
preston> cleaning up addressing expressions -- things that arise when
preston> compiling


preston> A(i, j) = A(i-1, j) * B(i, j-1)


preston> It's the sort of thing C programmers can get at using pointer
preston> arithmetic, but most other languages must leave alone.


But that's the problem with those languages -- they have the unfortunate
property (an architectural tragedy!) of not being low level enough that
the programmer can specify what sort of code he wants (as say in C and
other true to form MOHLL/systems implementation language), and not high
level enough that the compiler can generate the sort of code it wants
(as say in SQL and other true to form application oriented languages).


preston> I remember C. A. R. Hoare writing persuasively for a language
preston> in which "a simple straightforward 'non-pessimising' compiler
preston> will produce straightforward object programs of acceptable
preston> efficiency."


And myself on these screens, in a less important way, I have been
echoing Hoare's opinions (which are Thompson's as well, I understand).


preston> To an extent, C and its early compilers accomplish this,


Yes, it being a systems implementation language.


preston> but the amount of detail required of the programmer seems
preston> extreme.


That's a question of taste, but you only need to take great care when it
matters, which is usually rarely. Most of almost every application does
not need any automatic/manual optimization.


preston> Therefore, I'd advocate writing clean, straightforward code
preston> that correctly expresses the algorithm you've carefully
preston> selected


Yes, precisely, but I see that very few people are using APL/S instead
of Fortran or SQL/Equel instead of Cobol.


preston> and let the compiler worry about the low level tedium that they
preston> were designed to handle.


If the language defines a suitably abstract interface between programmer
and compiler, that's wonderful. If the interface is at the wrong level
of abstraction, or incomplete, this becomes program rewriting by the
compiler, and it is dangerous and expensive.


Unfortunately a lot of people with the bucks to purchase compilers have
Cobol/Fortran/... dusty decks.
--
Piercarlo Grandi | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
--

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