Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing a C Compiler: Build a Real Programming Language from Scratch

nostarch.com

Post reply on HN
Print view View original

61–70 of 159 posts

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#61

Post by anta40 »

badsectoracula wrote: post #15

Weird that this is about building a C compiler[0] in OCaml . I expected the implementation language to also be C both for consistency but also because i'm willing to bet that there are more people who can read C than OCaml. [0] actually from the readme in the github repo[1] it seems to be a C subset, not all of C [1] https://github.com/nlsandler/nqcc2

Written in OCaml? Ahh interesting. Suddenly I remember similar book:

Modern Compiler Implementation in ML: https://www.cs.princeton.edu/~appel/modern/ml/

As an undergrad student, I think the C version is kinda easier to understand, though.

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#62

Post by materielle »

hdbxbxndj wrote: post #30
Croftengea wrote: post #20

Earlier quoted context omitted.

OCaml? Thanks for saving me a click!

OCaml is one of the most used languages for compiler design A good engineer should be able to use the right tool for the job

For hobbyist compiler implementations, right? Compilers for the most popular languages are either written in C/C++, or self-hosted.

You can write compilers in almost any language. I fail to see how C, C++, or even Java or Python aren’t the right tool for the job here. I like pattern matching too, but given that hundreds of successful production compilers have been written without pattern matching, it’s surely just a personal preference.

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#63

Post by pklausler »

kragen wrote: post #27
mjburgess wrote: post #16

Earlier quoted context omitted.

Parser-generators were always academic projects that had little relevance to making real-world programming languages -- where parsing is very easy to write, and necessarily benefits from doing it (ie., you can get better error handling/etc.). Today most languages are front-ends for LLVM IR, but LLVM is very slow and takes a long time to optimize. Many new languages target x86/arm directly with their own weakly optimi…

yacc/bison was used for lex, bc, pcc, gcc, original awk, the bsd pascal compiler, eqn, m4 (!), and many other languages. it's still used for pcc, oawk, mawk, pari/gp, and units. that's just what i have sitting around in my downloads directory and, while we're talking about ocaml, ocaml does use ocamllex and ocamlyacc for its own parser so, while you can certainly do without parser generators, they have very commonly…

Fortran compilers did go through a phase when table-driven parsers were used, but it had the disadvantage of needing complicated lexers and statement classifiers that rely on semantic information. Fortran’s a hard language to parse, given its lack of reserved words, optional spaces, and many ambiguities.

The f18 compiler’s parser uses parser combinations to construct a backtracking recursive descent parser that builds a parse tree for the whole source file before doing any semantic analysis. This approach allows good error recovery without having to revert any updates to the symbol table.

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#65

Post by trealira »

hasbot wrote: post #14

So what's different about writing a compiler in 2024 than say 10, 20, or 30 years ago? When I started writing compilers in the 80's and 90's lex/flex and yacc/bison were popular. ANTLR came out but I never had a chance to use it. Everything after lexing and parsing was always hand rolled.

The book doesn't have 2024 in the title. I suspect they put it there because last time a post about this book was made, I noted that it was from 2022, not realizing that the book has now been released in 2024.

https://news.ycombinator.com/item?id=40940799

> So what's different about writing a compiler in 2024 than say 10, 20, or 30 years ago?

As far as I can tell, the main difference is that static single assignment (SSA) as an intermediate form was not the norm 30 years ago, but it is nowadays. Also, in newer books, it's more common to go over global register allocation now, whether that's graph coloring or linear scan register allocation. If you read old compiler books, the main optimizations they talk about are use-def chains, moving computations out of loops, and using the local and tree-based Sethi-Ullman register allocation algorithm.

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#66

Post by kragen »

pklausler wrote: post #63
kragen wrote: post #27

Earlier quoted context omitted.

yacc/bison was used for lex, bc, pcc, gcc, original awk, the bsd pascal compiler, eqn, m4 (!), and many other languages. it's still used for pcc, oawk, mawk, pari/gp, and units. that's just what i have sitting around in my downloads directory and, while we're talking about ocaml, ocaml does use ocamllex and ocamlyacc for its own parser so, while you can certainly do without parser generators, they have very commonly…

Fortran compilers did go through a phase when table-driven parsers were used, but it had the disadvantage of needing complicated lexers and statement classifiers that rely on semantic information. Fortran’s a hard language to parse, given its lack of reserved words, optional spaces, and many ambiguities. The f18 compiler’s parser uses parser combinations to construct a backtracking recursive descent parser that build…

that's an interesting approach! though probably not applicable to c and c++

i assume that by 'parser combinations' you mean parser combinators

what i meant about fortran is that the first fortran compiler didn't use a parser generator

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#67

Post by porcoda »

materielle wrote: post #62
hdbxbxndj wrote: post #30

Earlier quoted context omitted.

OCaml is one of the most used languages for compiler design A good engineer should be able to use the right tool for the job

For hobbyist compiler implementations, right? Compilers for the most popular languages are either written in C/C++, or self-hosted. You can write compilers in almost any language. I fail to see how C, C++, or even Java or Python aren’t the right tool for the job here. I like pattern matching too, but given that hundreds of successful production compilers have been written without pattern matching, it’s surely just a…

I’ve worked on multiple compilers in industry that are written in Ocaml. A number of industrial static analyzers are written in Ocaml too (eg, Infer from Facebook/Meta). Yes, LLVM and GCC are the big ones written in the C/C++ family but they don’t represent everything.

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#68

Post by vulcan01 »

stefanos82 wrote: post #46
mjburgess wrote: post #40

Earlier quoted context omitted.

I was immediately thinking of Jai, Zig, .. but I've seen a few

Correct me if I'm wrong, but I think both Zig and Jai use LLVM as their default backend...at least, that's what I have seen via live streaming for Jai, and from Zig's repo.

Zig is moving away from LLVM (https://github.com/ziglang/zig/issues/16270) and Rust has added Cranelift as a debug backend (https://lwn.net/Articles/964735/).

Not sure about Jai.

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#69

Post by dymk »

fuhsnn wrote: post #37
alok-g wrote: post #35

Earlier quoted context omitted.

I understand that assembly file can be parsed in the same way. However, I want to learn about the machine instructions to the level of bits, and likewise the layouts of binary files. Unless I am able to go all the way to machine code loaded in memory, I would not know where in memory to add a breakpoint instruction when a developer wants the same on a line of code. If there is some library that can help create machin…

>If there is some library that can help create machine code from assembly instructions on a line by line basis That's what JIT libraries do, for example asmjit: https://github.com/asmjit/asmjit/blob/master/test/asmjit_tes...

asmjit is great; I used it for building a primitive (but quite fast) query engine for in-memory graphs. It made it simple to go from query AST to native instructions, most of which was "call this other compiled function".

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#70

Post by mananaysiempre »

the_panopticon wrote: post #64

In Ocaml, interesting. I was similarly surprised when I learned that the firs Rust compiler was written in Ocaml, too https://users.rust-lang.org/t/understanding-how-the-rust-com...

Tree processing is best done in a language with decent algebraic datatypes and pattern matching. I would’ve preferred Standard ML, but, well, pot-ay-to, pot-ah-to. Haskell is another choice but the techniques you need to use there (while undeniably gaining you some possibilities) don’t really generalize to other languages, so you’re now writing a book about compiler construction in Haskell rather than just compiler construction. Ditto for Rust. Kotlin has deliberately anemic pattern matching. C# or F# leave you depending on Microsoft’s benevolence (sic). Metalua and Sweet.js both have decent ADT support but both are pretty much dead. Racket exists, I guess, and there are some pattern-matching libraries for normal Scheme as well, but the charisma malus of the parenthesis is real even if I don’t understand what causes it.

So OCaml was probably the most mainstream choice among the languages with appropriate tools, as funny as that sounds. And honestly, once you get over the syntax, it doesn’t actually have anything outrageous.

Post reply on HN