
Compiler Construction: The Art of Niklaus Wirth (2000) [pdf] - ingve
https://pdfs.semanticscholar.org/036f/c4effda4bbbe9f6a9ee762df717bd0af1324.pdf
======
userbinator
_Generate good code from the beginning; don 't generate bad code and optimize
later_

Unfortunately this is something that no compiler I know of does, as evidenced
by their -O0 being far worse than even what a naive Asm programmer (human)
could do, and it's one of the things that irks me about compilers. Dataflow-
directed, "work backwards" techniques might be the solution to this, but once
again I don't know of any compilers that do it.

On the other hand, his points about using recursive-descent parsing seem to
agree with the majority of widely-used compilers. However, this is factually
incorrect:

 _I even think that the availability of powerful bottom-up parser generators
such as Yacc are responsible for the cryptic syntax of C._

Dennis Ritchie's first C compiler used recursive descent. Yacc itself was
written in C, so it could not have come before. You can see the sources
yourself here:
[https://news.ycombinator.com/item?id=5748672](https://news.ycombinator.com/item?id=5748672)

~~~
vidarh
>> Generate good code from the beginning; don't generate bad code and optimize
later

> Unfortunately this is something that no compiler I know of does,

You're probably right compared to modern compilers. What you need to compare
to are the compilers of the era, which were truly abysmal.

It's not that the Wirth compilers generated fantastic code (e.g. at least one
of Wirths students explored adding much more aggressive optimization to his
Oberon compiler), but they generated code that was a great deal better than a
lot of non-Wirth style compilers at the time.

Some compilers of the time even depended on peephole optimizer passes because
the code they generated was so bad that even simple 2-3 instruction peephole
passes were enough to drastically improve the code. There was little reason
for this. E.g. most of the time it was a matter of as basic stuff as passing
on information about the registers to use rather than the dumb/naive approach
of generating everything using scratch registers that you move things to/from.

I remember back in my asm days that I once had the C source for a GUI
component I wanted to use, but the code the C compiler I had available
generated was so awful that in exasperation I compiled it, disassembled it,
and proceeded to manually clean it up. I deleted about half the instructions
of about several thousand lines of compiler output, with very minimal fixups.

~~~
lboasso
Wirth's compilers generated reasonably good code: 80% of the performance of
optimizing compilers with 20% of the effort.

The first Java client jit compiler, was developed by Robert Griesemer (former
PhD student of Wirth). The design of the compiler is described in the paper "A
compiler for the java hotspot virtual machine", published in the same book:
"The School of Niklaus Wirth: The Art of Simplicity".

------
lboasso
I wrote a simple self-hosting compiler to showcase Niklaus Wirth's approach to
writing compilers:
[https://github.com/lboasso/oberonc](https://github.com/lboasso/oberonc)

Single pass compilers have their advantages.

~~~
sitkack
"The School of Niklaus Wirth" [0] contains this essay and many others on how
simplicity can be an essential quality of a system. I vastly under appreciated
how well Wirthian languages are designed, even after toying with the excellent
offshoot, Modula3 [1]. In my youth I was too concerned with raw performance
and syntax. In my old age I am concerned about semantics and maintainability.

[0] [https://www.amazon.com/School-Niklaus-Wirth-Art-
Simplicity/d...](https://www.amazon.com/School-Niklaus-Wirth-Art-
Simplicity/dp/1558607234)

[1] [https://github.com/modula3/cm3](https://github.com/modula3/cm3)

~~~
lboasso
I own a copy of "The School of Niklaus Wirth" :) I really appreciate the
pragmatism of Wirth's designs and his quest for simplicity.

------
mojuba
> Don't let the compiler repair poor programming style ... This includes some
> cases of common subexpression elimination, loop invariant code motion and
> copy propagation

Unfortunately in languages like C++ these inefficiencies often originate from
inline function expansion rather than the programmer and thus are absolutely
necessary.

> Strive for short compilation times

I wish designers of Swift heard this... Swift's build times can be
horrifically slow for no good reason, it seems. I think slow build times have
become a new norm pretty much like e.g. graphics display boot up times, i.e.
someone at some point convinced the users that it's the way it should be and
as a new norm no vendor strives to improve it.

~~~
fao_
> someone at some point convinced the users that it's the way it should be and
> as a new norm no vendor strives to improve it.

People tend to defend slow boot up times with arguments that boil down to the
aphorism:

Better the code be correct than fast.

Unfortunately most modern software out there is neither, which is where the
whole argument falls apart.

------
pedrow
As a matter of interest do we know when this was written? The PDF has a date
of 2007 but the latest reference is Wirth's book, published in 1996.

~~~
vidarh
This looks to be the original publication [1]:

Hanspeter Mössenböck: Compiler Construction - The Art of Niklaus Wirth.
Chapter in: Böszörmeny et al.(eds): The School of Niklaus Wirth, dpunkt.verlag
2000, pp.55-68

An extensive list of Mössenböck's publications can be found here[2]

[1]
[http://ssw.jku.at/Research/Papers/Moe00b.html](http://ssw.jku.at/Research/Papers/Moe00b.html)

[2] [http://ssw.jku.at/Research/Papers/](http://ssw.jku.at/Research/Papers/)
(while this from the page looks like it's for his institute, it looks like all
of them have him as at least co-author, and they include papers from his past
institutions including his time at ETHZ with Wirth; e.g. a favourite of mine
of his earlier paper is this collaboration with Marc M. Brandis on generating
SSA forms for structured languages in a single pass [3] from '94 - as a
confessed Niklaus Wirth fanboy I read most of the papers that came out of his
research group in the early 90's..)

[3]
[http://ssw.jku.at/Research/Papers/Moe94.html](http://ssw.jku.at/Research/Papers/Moe94.html)

EDIT: I of course had to check, and Amazon (at least in the UK) has the book
this is from (The School of Niklaus Wirth: The Art of Simplicity ), though
it's expensive... I just had to share this hilarious find from one of the
reviews:

"For me, this book is one to keep forever. I enjoyed every page (apart from
the section written by Dijkstra since it was handwritten..)."

EDIT2: And having been seduced into buying this book, I can confirm Dijkstra's
contribution (On the transitive closure of a well founded relation; dedicated
to Niklaus Wirth) is in fact included in his handwritten form. I wish I had
handwriting like that (but not enough to put in the effort).

~~~
tom_mellior
> in: Böszörmeny et al.(eds): The School of Niklaus Wirth

I used to have that book somewhere. All of it was nicely typeset, except for
Dijkstra's chapter, which was facsimile copies of (nicely) handwritten text.

~~~
vidarh
His handwriting is fantastic. And it's such an obvious fun little quirk given
how famous he is for his handwritten notes.

