Goodness, this takes me back to a my junior year of my Computer Science undergrad degree. One of my classes was one long project of writing a compiler to handle the professor's made up programming language.
Hah, I had exactly the same experience. I followed a compilers course and the task was similar, but we had to use some whack compiler framework without any documentation. Apparently the professor was the only user of the framework, but nobody dared to ask any questions about it because the professor would ridicule you if you asked any question that was not an open research problem.
I took compilers twice— I had to drop it the first time because I chose to use a different language and tools than the rest of the class, and the parser generator I chose didn't accommodate the kinds of error messages we needed to produce. The issue only became clear to me a few months into the class.
The second time I took it, things were relaxed a bit— the curriculum was designed around working in a high-level language (Java) and we got to write an interpreter for a nice intermediate form based on a simple VM instead of compiling all the way down to machine code.
So there were definitely some differences and they did make things easier! But I still remember this as one of my favorite classes, and I'd love to take it again and go 'all the way'.
It seems like a lot of CS majors find compilers to be the hardest course of the degree, indeed, it was the capstone for my degree. I found it to be quite fun and not particularly intensive once you wrapped your head around each new concept. I found CS Theory and Operating Systems to be much more difficult material, although both of those courses had less actual work.
I actually like that the code is in turbo pascal and that it targets M68k assembly, because that way the modern reader is encouraged to pick their own implementation language and target ISA, and you have to make sure you understand the code snippets well enough to translate the logic into your chosen language instead of just copying.
I learned from Crenshaw's tutorial many years ago, and it inspired me to go write my own 3-part tutorial for my students: Let's make a Teeny Tiny compiler.
Although AI has been all the rage lately, I was actually always excited the most by building a compiler. After a few years of dabbling with it, I created one together with my brother: https://github.com/wasp-lang/wasp
It is a DSL (a simple config language for building web apps) so not that complicated as a Turing-complete language, but still a lot of concepts remain.
As a good starting resources for building your own compiler I'd also recommend Crafting Interpreters, super nicely explained and fun to go through: https://craftinginterpreters.com/
This series got me into coding languages for work and fun. I wish more books about complex topics were written this way... For anyone who's interested, Jack Crenshaw did an interview in 2009 and touched upon how he wrote this series. [1]
Definitely brings back memories, this was the guide I used for my first experiments in building compilers. It was also the first real standalone project I worked on outside of college, I was just learning to use Git at the time...it was a mess in many ways, but it got me started. That said, I'd say https://craftinginterpreters.com/ is a much better way to get started these days.
I own just about all the compiler construction books. Most were over my head. Then I discovered chapter 8 of "The Unix Programming Environment" by Brian Kernighan and Rob Pike. This is "Program Development", explaining all the tools one would use to write C programs. Their example, however, is a compiler. Unlike most introductions, they don't just show a 4 function calculator. They go on to add variables, control flow, and functions, making this a really great way to start building languages. Highly recommended, and a hidden jewel. (The full text is readily available on the net.)
BYTE magazine in the 70's published the source to a complete Pascal compiler as an article! Having no idea how compilers worked, I studied that code from stem to stern. Best BYTE issue ever!
20 comments
[ 4.3 ms ] story [ 49.6 ms ] threadI find it more readable. YMMV.
That was a long semester.
The second time I took it, things were relaxed a bit— the curriculum was designed around working in a high-level language (Java) and we got to write an interpreter for a nice intermediate form based on a simple VM instead of compiling all the way down to machine code.
So there were definitely some differences and they did make things easier! But I still remember this as one of my favorite classes, and I'd love to take it again and go 'all the way'.
Why do you say it was a 'long semester'?
I actually like that the code is in turbo pascal and that it targets M68k assembly, because that way the modern reader is encouraged to pick their own implementation language and target ISA, and you have to make sure you understand the code snippets well enough to translate the logic into your chosen language instead of just copying.
https://austinhenley.com/blog/teenytinycompiler1.html
It is a DSL (a simple config language for building web apps) so not that complicated as a Turing-complete language, but still a lot of concepts remain.
As a good starting resources for building your own compiler I'd also recommend Crafting Interpreters, super nicely explained and fun to go through: https://craftinginterpreters.com/
[1] http://www.trs-80.org/interview-jack-crenshaw/
But it's worth noting that the code as published is an interpreter, not a compiler:
https://en.wikipedia.org/wiki/Hoc_(programming_language)
https://archive.org/details/byte-magazine-1978-09 (part 1)