Book: Compiler Construction, by Niklaus Wirth [pdf]

Great link Peter! Just the sort of info I am looking for at the moment as well...

That can be good, though - so many compiler texts go into heavy detail about LALR parsing algorithms, etc., and it's hard to get a sense of how it all ties together.

Abdulaziz Ghuloum's "An Incremental Approach to Compiler Construction" (http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf) is great, too!

I went through this series several years back and it was very good. I just wish Jack had finished it :(

I always enjoyed his writing style (embedded systems programming magazine - programmer's toolbox;, e.g.,http://www.eetimes.com/discussion/programmer-s-toolbox/40269... )

It seems to require turbo pascal to work. Is it possible to find this?

Porting of Crenshaw classic to Forth:

http://home.iae.nl/users/mhx/crenshaw/tiny.html

"Jack W. Crenshaw wrote the Let's Build a Compiler article series from 1988 - 1995. This document is a formatted version of that excellent non-technical introduction to compiler construction. These web pages were created in 2005, and port Mr. Crenshaw's original Pascal code for the 68000 under SK*OS to the Forth language on a 80x86 CPU, under Windows XP."

And porting to Haskell: http://alephnullplex.appspot.com/blog/view/2010/01/12/lbach-...

Life was so much simpler back in the olden times when people worked 6 days a week, there wasn't the same demands on time.

What? Oberon is the simplest language to implement, I know, I did .. in Lisp.

Here is a text that shows you how, and it's free:

http://homepages.cwi.nl/~steven/pascal/book/pascalimplementa...

There is another book, whose very generic name escapes me. It's a compiler book using Pascal; it went out of print in the late 80s. That one had invaluable tricks about code generation and optimizing for obsolete processors. There are Z-80 chips still in the market, and that book was the only one that I know of that had algorithms on code generation for accumulator machines. Somebody please prove me wrong!

I got my copy of it for fifteen U.S. cents from a local university. The inside of the back cover has those old pockets for keeping library book cards; it was checked out from the library roughly 4 times and it has been on the shelf at least since 1976, the earliest checkout stamp on the card! Here is the kicker; I enrolled in that university for one cheap class, and spent the whole semester extending and renewing the book every time it was due. You see, In 26 years, I was the only person to have borrowed it, and I did so 3 times. Imagine my surprise one day when I went in to browse the shelves, and I saw the book at the library entrance a mid a pile of National Geographics and Popular Mechanics rags. What a treasure! I didn't have $0.15, so I gave them a quarter and donated the change to hire education. I wonder what IT certification book they replaced it with.

It depends both on the models for compilation you're using and the resulting language model the programmer has to deal with. The "barrier between the mind and the computer" is only there if you have a mismatched conceptualization. A language using a graph isn't needed for hierarchical problems; a language using a tree isn't needed for linear problems.

If you want simple, you can't get much simpler than a Forth or assembly language. Lisp is slightly more difficult than those other two because it has explicit hierarchical structures - and thus it needs a parsing strategy more complex than "consume tokens." Lisp also needs more complex memory management strategies to be a useful production system.

If you want a safe/productive environment, the tendency is to add more syntax and a tighter runtime model than either Forth or Lisp. Adding syntax is a tradeoff between simplicity and ambiguity....while nobody likes syntactical monstrosities, nobody wants to program at the conceptual level of the lambda calculus or Turing machine, either. With low-syntax languages, programmers must concern themselves with ambiguous statements that would be caught at compile time elsewhere. As well, locking down the runtime model to bias only towards necessary tasks gives the language a focus that motivates the rest of its environment(optimizations, libraries, build systems, etc.). C, for example, was built for Unix, and that coexistence has led to its astounding long-term success.

Lisp is great for a lot of things, but that's also its downside. To rephrase Dijkstra: "Flexibility considered harmful."