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
Writing a C Compiler: Build a Real Programming Language from Scratch
81–90 of 159 posts
Re: Writing a C Compiler: Build a Real Programming Language from Scratch
#82On topic, though: wouldn't a simpler language (maybe even a pseudo language) be a better target for a first learning compiler. I understand they don't build a full C compiler, but still. It looks to me like there's a lot of complexity add from choosing such a lofty target.
Re: Writing a C Compiler: Build a Real Programming Language from Scratch
#83Re: Writing a C Compiler: Build a Real Programming Language from Scratch
#84https://archive.org/details/byte-magazine-1978-09 (part 1)
All 3 parts of Tiny Pascal:
https://albillo.hpcalc.org/publications/Easter%20Egg%20-%20T...
Re: Writing a C Compiler: Build a Real Programming Language from Scratch
#85I learned how to write a compiler by studying BYTE magazine in the 70's which published the source to a complete Pascal compiler as an article! https://archive.org/details/byte-magazine-1978-09 (part 1) All 3 parts of Tiny Pascal: https://albillo.hpcalc.org/publications/Easter%20Egg%20-%20T...
Re: Writing a C Compiler: Build a Real Programming Language from Scratch
#86Earlier quoted context omitted.
Many compiler related books take inspiration from the "Dragon book" (Compilers: Principles, Techniques and Tools). So with likely lots of books with similar looking covers.
The cover looks nothing like the dragon book however?
Like if I’d see the book on a shelf I would instantly guess it’s related to compilers. And I bet that’s completely intentional homage to the original.
Re: Writing a C Compiler: Build a Real Programming Language from Scratch
#87Earlier quoted context omitted.
>just a simple case of bad code generation render little compiler into a toy one If you find some time to go through gcc bugzilla you'll find shockingly simple snippets of code that miscompiled (often by optimization passes), with fixes never backported to older versions that production environments like RHEL are using.
Ok, but that’s sw engineering issue. I still insist that a production grade compiler can’t leave performance on table. Which is where the current battlefield is.
Re: Writing a C Compiler: Build a Real Programming Language from Scratch
#88I see many comments saying that the book implements the C compiler in ocaml. In the introduction the author states that the book actually uses pseudo code so you are actually free to implement it in any language. The only recommendation is that you use a language with pattern matching because the pseudo code makes heavy use of it. The reference implementation is in ocaml.
Re: Writing a C Compiler: Build a Real Programming Language from Scratch
#89Earlier quoted context omitted.
>just a simple case of bad code generation render little compiler into a toy one If you find some time to go through gcc bugzilla you'll find shockingly simple snippets of code that miscompiled (often by optimization passes), with fixes never backported to older versions that production environments like RHEL are using.
Ok, but that’s sw engineering issue. I still insist that a production grade compiler can’t leave performance on table. Which is where the current battlefield is.
Re: Writing a C Compiler: Build a Real Programming Language from Scratch
#90So 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.
That "middle-pass" approach that will let you address many targets is still valid; the trick is finding a sufficiently robust and flexible internal representation at the right level. You also have to be able to out-guess the chip vendors where before you could go to the architect or a complete "System" book and get the real scoop, including things you shouldn't do. Oddly enough, there is simultaneously useful and completely worthless documentation scattered about the internet.
You might want to take a look at Muchnick and Jones' _Program_Flow_Analysis_ (yes, it's from 1981) but chapters 4-6 can be applied at code-generation time. How that fits modern Intel processors (for example) is unknown. Idealizing your processor as a RISC-V might be a reasonable way to proceed but in the end, you'll have to translate the code for the target -- it will be reasonably straight-forward if you drive it all from tables but it's not trivial.