compiler writing is always a journey apparently....
> "In the four years since
installment fourteen, I've managed to get laid off, get divorced,
have a nervous breakdown, begin a new career as a writer, begin
another one as a consultant, move, work on two real-time systems,
and raise fourteen baby birds, three pigeons, six possums, and a
duck. For awhile there, the parsing of source code was not high"
on my list of priorities.
C and AT&T syntax... because it's not Real Programming™ unless there's cryptic symbols everywhere, everyone today knows that of course! [/s]
And then there is some weirdly phrased misinformation in the readme about how on modern OSes you have to link to libraries - this simply isn't true, at least on Linux. A static 32-bit binary using either 'int 80h' or 'syscall' instructions will even run on "pure" x64 systems (i.e. ones with no 32-bit libs installed at all).
The only thing this adds is the translated code, and this dubious information about x86 programming, the text of the tutorial itself is unchanged. So I don't see this providing any value except to those people who absolutely refuse to read Pascal code.
To anyone who wants a similar bottom-up (but somewhat more advanced) compiler tutorial using C, maybe read this one instead: https://github.com/DoctorWkt/acwj
It seems that in many compiler resources (even the modern ones), there is still a lot of focus on the front-end—things like lexing, parsing, DFAs, regex matching, recursive descent.
I would like to see greater focus on the back-end: optimisation strategies like dead code elimination, register allocation, parallelisation, vectorisation, detecting SIMD-able code, and even whole-program optimisation.
Even on the front-end, it would be nice to see focus on the failure cases—printing nicely formatted error messages, for instance.
IMO these are strictly larger contributors to the quality of a compiler suite than merely lexing and parsing, which are generally solved problems.
17 comments
[ 2.9 ms ] story [ 48.0 ms ] thread"This is a prettified and modern, browsable version of Let’s Build a Compiler by Jack Crenshaw."
> "In the four years since installment fourteen, I've managed to get laid off, get divorced, have a nervous breakdown, begin a new career as a writer, begin another one as a consultant, move, work on two real-time systems, and raise fourteen baby birds, three pigeons, six possums, and a duck. For awhile there, the parsing of source code was not high" on my list of priorities.
https://www.resonancepub.com/jack-crenshaw/
It's been a while I saw it.
https://github.com/lotabout/Let-s-build-a-compiler
And then there is some weirdly phrased misinformation in the readme about how on modern OSes you have to link to libraries - this simply isn't true, at least on Linux. A static 32-bit binary using either 'int 80h' or 'syscall' instructions will even run on "pure" x64 systems (i.e. ones with no 32-bit libs installed at all).
The only thing this adds is the translated code, and this dubious information about x86 programming, the text of the tutorial itself is unchanged. So I don't see this providing any value except to those people who absolutely refuse to read Pascal code.
To anyone who wants a similar bottom-up (but somewhat more advanced) compiler tutorial using C, maybe read this one instead: https://github.com/DoctorWkt/acwj
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 - https://news.ycombinator.com/item?id=20444474 - July 2019 (47 comments)
Let's Build a Compiler (1995) - https://news.ycombinator.com/item?id=19890918 - May 2019 (18 comments)
Let’s Build a Compiler (1995) - https://news.ycombinator.com/item?id=6641117 - Oct 2013 (56 comments)
Let’s Build a Compiler (1995) - https://news.ycombinator.com/item?id=1727004 - Sept 2010 (17 comments)
Let’s Build a Compiler (1995) - https://news.ycombinator.com/item?id=232024 - June 2008 (5 comments)
Let's build a compiler (dated, but very good) - https://news.ycombinator.com/item?id=63004 - Oct 2007 (2 comments)
I would like to see greater focus on the back-end: optimisation strategies like dead code elimination, register allocation, parallelisation, vectorisation, detecting SIMD-able code, and even whole-program optimisation.
Even on the front-end, it would be nice to see focus on the failure cases—printing nicely formatted error messages, for instance.
IMO these are strictly larger contributors to the quality of a compiler suite than merely lexing and parsing, which are generally solved problems.