Working through 'Writing A C Compiler' • Hacker News Board

Re: Working through 'Writing A C Compiler'

#41

Post by sanufar » Sun, Jul 13, 2025, 2:57 PM UTC

rootnod3 wrote: post #39

sanufar wrote: post #16

I love this book! I worked through a bunch of it during my winter break last year and found the incremental teaching style extremely rewarding. For readers of the book, Sandler’s reference OCaml implementation is super useful for getting your bearings. I was kind of thrown off by the use of TACKY as an IR, but it was nice to have a solid reference as I worked through the book. For those more experienced with compiler…

There’s https://www.amazon.com/SSA_based-Compiler-Design/dp/30308051...

This looks great! Added that and this https://www.amazon.com/Engineering-Compiler-Keith-D-Cooper/d... to my list

Re: Working through 'Writing A C Compiler'

#42

Post by pshirshov » Sun, Jul 13, 2025, 3:54 PM UTC

My personal experience of writing various DSL/general purpose compilers (I've created at least 4 DSL compilers and one general purpose) is kinda different from the books I've read.

Scala is an awesome language which frees one from working on many boring details and makes it possible to keep the codebase tiny. With such an expressive language I can concentrate on the logic instead of thinking about minor things.

We have enough memory and cpu power to use worse than linear algorithms without noticeable performance impact.

Parsers aren't an issue at all in our days, peg combinators like fastparse allow one to be extremely productive.

I tend to stick to immutable multi-staged pipelile with several immutable trees, use error-accumulating data structures (Either[NonEmptyList[Issue], T]), explicitly express entity (eg type definition) dependencies as graphs (which can be processed iteratively and in parallel).

Re: Working through 'Writing A C Compiler'

#43

Post by UncleEntity » Sun, Jul 13, 2025, 5:47 PM UTC

markus_zhang wrote: post #29

UncleEntity wrote: post #12

Earlier quoted context omitted.

> The crafting interpreting asks the reader to use the visitor pattern... ...or just a big old, plain jane switch statement. In my current project I modified my ASDL generator to output a C instead of C++ AST and the visitor pattern carried over until realizing a switch statement is just as good (or better) in C so I ripped out that part of the template file. The choice was to write a dispatch function which called t…

I think I did something similar for an emulator. Instead of using a big switch I simply used a big array of function pointers. So if it is a BLAH opcode, the execution code simply call fp_list[BLAH](op). But I guess it is a bit too much for CPUs that have tons of operations.

I actually use that pattern in the VM just with a dispatch function instead of calling the function out of the array directly. The compiler (more than likely) inlines the dispatch call and it let's me add some error checking on the opcode without it being scattered all over the instruction functions.

The Next Big Trick™ is to just embed the function pointer into the opcode itself and do away with the dispatching completely, getting rid of a single pointer dereference per opcode has to be worth at least a 0.01% speed gain, right? I'm kidding, of course, as the original copy and patch (using C labels as references to mark the code boundaries of the code templates) should allow actual measurable gains in the single digit range.

Re: Working through 'Writing A C Compiler'

#44

Post by jokoon » Sun, Jul 13, 2025, 7:24 PM UTC

almostgotcaught wrote: post #8

jokoon wrote: post #3

The crafting interpreting asks the reader to use the visitor pattern, and this was quite a turn off for me, I stopped there.

Lolol weirdest reason to reject that book - 90% of production parsers are recursive descent parsers.

I think the book claims to be accessible and easy

The visitor pattern is not something I find simple and easy to approach