> Rather than getting stuck in front-end minutiae, the tutorial goes straight to generating working assembly code, from very early on. I think this is important and for a more sophisticated compiler design I find Ghuloum approach very appealing [1]. I.e. build a very simple subset of the language from top to bottom and then grow the meat gradually. The really great book following this approach I've discovered recentl…
This is something I've noticed on academic vs "practicing" coders. Academics tend to build in layers, though not always, and "practicing" coders tend to build in pipes give or take. The layers approach might give you buildable code, but is hard to exercise and run. Both approaches can work though, especially if you build in executable chunks, but you have to focus on the smallest chunk you can actually run.
Revisiting "Let's Build a Compiler"
41–50 of 53 posts
Re: Revisiting "Let's Build a Compiler"
#42Naturally, the author has also written an article about it, albeit without the explanation of the refactoring that links it to RD:
https://eli.thegreenplace.net/2012/08/02/parsing-expressions...
Re: Revisiting "Let's Build a Compiler"
#43This article sums it up perfectly. I was interested in building a compiler long before going to college and this was the most accessible body of work. Building a recursive descent parser from scratch was an eye opener to 17yo me on how a seemingly very complex problem that I had no idea how to approach can be made simple by breaking it down into the right primitives.
That's a good point - recursive descent as a general lesson in program design, in addition to being a good way to write a parser. Table driven parsers (using yacc/etc) used to be emphasized in old compiler writing books such as Aho & Ullman's famous "dragon (front cover) book". I'm not sure why - maybe part efficiency for the slower computers of the day, and part because in the infancy of computing a more theoretical…
That is basically an AST interpreter.
Re: Revisiting "Let's Build a Compiler"
#44This article sums it up perfectly. I was interested in building a compiler long before going to college and this was the most accessible body of work. Building a recursive descent parser from scratch was an eye opener to 17yo me on how a seemingly very complex problem that I had no idea how to approach can be made simple by breaking it down into the right primitives.
When I need to parse something nowadays I always end up with parser combinators. They just make so much sense.
Re: Revisiting "Let's Build a Compiler"
#45Revisiting "Let's Build a Compiler" threads: Let's Build a Compiler (1988) - https://news.ycombinator.com/item?id=38773049 - Dec 2023 (15 comments) Let's Build a Compiler (1988) - https://news.ycombinator.com/item?id=36054416 - May 2023 (19 comments) Let’s Build a Compiler (1995) - https://news.ycombinator.com/item?id=22346532 - Feb 2020 (41 comments) Let's Build a Compiler (1995) - https://news.ycombinator.com/item?…
Re: Revisiting "Let's Build a Compiler"
#46Re: Revisiting "Let's Build a Compiler"
#47Earlier quoted context omitted.
That's a good point - recursive descent as a general lesson in program design, in addition to being a good way to write a parser. Table driven parsers (using yacc/etc) used to be emphasized in old compiler writing books such as Aho & Ullman's famous "dragon (front cover) book". I'm not sure why - maybe part efficiency for the slower computers of the day, and part because in the infancy of computing a more theoretical…
Rather than having the recursive descent parser generate code, I just had it generate executable data structures - subclasses of Statement and Expression base classes, with virtual Execute() and Value() methods respectively, so that the parsed program could be run by calling program->Execute() on the top level object. That is basically an AST interpreter.
Re: Revisiting "Let's Build a Compiler"
#48Earlier quoted context omitted.
Wirth also wrote an extremely accessible book on Compiler Construction, using exactly the hand written recursive descent parsing approach discussed by OP. The initial edition was published in 1976, in German, but the latest version is available online: https://people.inf.ethz.ch/wirth/CompilerConstruction/Compil... There are also parser generators like ANTLR ( https://en.wikipedia.org/wiki/ANTLR ) which take an input…
Thank you. Just to confirm, by "accessible", do you mean easy to understand? Anyway, I think I had come across that book on the net, but did not check it out at the time. I don't remember the exact reason, maybe it was because I didn't want to go into the subject of compilers at the time, and was only interested in interpreters, because I prefer to take things one step at a time. Now I will check it out.
Re: Revisiting "Let's Build a Compiler"
#49Revisiting "Let's Build a Compiler" threads: Let's Build a Compiler (1988) - https://news.ycombinator.com/item?id=38773049 - Dec 2023 (15 comments) Let's Build a Compiler (1988) - https://news.ycombinator.com/item?id=36054416 - May 2023 (19 comments) Let’s Build a Compiler (1995) - https://news.ycombinator.com/item?id=22346532 - Feb 2020 (41 comments) Let's Build a Compiler (1995) - https://news.ycombinator.com/item?…
The 4th one is not about Crenshaw's, but another article of the same name with very different contents.
(It was this one btw: Let's Build a Compiler - https://news.ycombinator.com/item?id=20444474 - July 2019 (47 comments) )
Re: Revisiting "Let's Build a Compiler"
#50For modern compiler and a more direct approach I recommend https://www.cs.cornell.edu/~asampson/blog/llvm.html
https://web.archive.org/web/20210208162458/https://www.cs.co...>
Discussed several times on HN: https://hn.algolia.com/?query=cs6120%20advanced%20compilers>
(And discussion about the blog post from last year about the IL used in the course: https://news.ycombinator.com/item?id=41084318>.)