Re: Language used to write compilers

"Joe H." <joe_hesse@actcx.com> wrote:


> I am thinking of taking a university course in compiler design. The
> instructor has chosen a book that teaches compiler implementation in Java.
> I always thought that compilers were usually written in C/C++.
>
> Question - what languages are used to write compilers? My world is
> Unix/Linux - should I wait until a course is offered using C/C++?


My advice for someone writing a compiler for the first time is to use
as high level a language as you possibly can. There are plenty of
languages readily available that are much higher level than Java (and
obviously vastly more so than C or C++).


There are three essential aspects to writing a good compiler (which
probably apply to most software anyway): it is well-designed; it is
correct; it is efficient. Of these three, the first two are far more
important than the third.


By "well-designed" I mean that the compiler has a good user interface,
in terms of switches, compiler directives, listing options, and (very
important) error diagnostics, as well as its implementation being
structured in a way that is conducive to testing and maintenance.


By "correct" I mean that the compiler always emits the right code: the
emitted code must have semantics compatible with the corresponding
source code, as defined by the source language (subject to any leeway
permitted by applicable compiler directives etc.).


A possible fourth aspect will be that the compiler emits
well-optimised code, if this is in fact a specific requirement of your
compiler.


You will almost certainly fail to produce a well-designed, correct
(optimising) compiler if you try to write it from scratch in a
low-level language (such as C or C++), however efficient it is.


To start with, forget efficiency, and concentrate on making the
compiler well-designed and correct. In particular, concentrate on
making the initial implementation highly testable/debuggable, and on
setting up a test mechanism that will give you very good assurance of
the compiler's correctness. Make sure that you can easily
trace/query/dump the internal state (e.g. of the symbol table and its
attributes) at any stage of the processing. It doesn't matter if,
initially, you use strings to store states, to make this sort of thing
easier. It doesn't matter if you use lots of phases, to make each
phase simpler. It doesn't matter if you use intermediate text files
between each phase, which you can then conveniently examine by
eye. Forget internal linking or emitting binary, to start with, and
just emit (pidgin) assembly.


Having achieved a well-designed, correct (optimising) compiler, you
can always then go on to concentrate on making it more efficient. Heed
my words! Good luck.
--
Nick Roberts

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