Jack Crenshaw's "Let's Build A Compiler" is another classic: http://compilers.iecc.com/crenshaw/ .. Back in the mid 90s, it's what got me into a continuing interest in compiler and interpreter development. It has a different audience to Wirth's, though. It's very entry level, almost "Dummies" level.
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.
"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."
It leans on Pascal, but when I first read it, I was waist deep in Turbo C. Luckily Pascal is almost pseudocode.. :-)
The Pascal is simple enough that, I suspect, FreePascal would be OK with it - http://www.freepascal.org/ - though getting Turbo Pascal 7 for DOS would be a real blast from the past.
Thanks for providing this link. I was not looking for this information but now that I have it I know I will use it. I have always wondered how compilers work and know that I will get a great amount of value out of this book and several others listed here. This is why it pays to hang around HN. Every once in a while gems like these show up.
Wow... this book is exactly why ALGOL languages suck. They create too much of a barrier between the mind and the computer. With a LISP much of this is not even required, because you create the syntax tree directly.
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.
Well, if you have a habit of calling family from overseas asking them to move your stuff from your apartment because you're "not coming back", well, crap happens.
Last year when I was "permanently moving to Australia", my family staged and intervention and forced me to for-once move my things to my parents' house first. My immigration lasted roughly 364 days, the maximum duration of a tourist stay :-P
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."
