> When I find a bug in this compiler, I go back to the original commit that introduced the bug and rewrite the commit history as if there were no such bug from the beginning. This is an unusual way of fixing bugs, but as a a part of a book, it is important to keep every commit bug-free.
Ooo la la! "Chibicc Vol. II, The Bugs" !?
In all seriousness, a book about the bugs would be (IMO) even more fun to read than the compiler book.
Oh man I used to be a die hard fan of the author's 'turing complete fm[1]' podcast. It seems like he has stopped publishing new episodes, wonder what happened.
I follow him on Twitter and I haven't seen any 'official' info reading the podcast.
But Mr.Rui did confirm in this thread that he would be continuing the podcast so seems like it
will continue :)
I quite like the learn-by-commit style. Look at a diff and see what changes it took to add a feature. Very good way of showing things in a format everyone is already familiar with.
Author here. No publishing date has been set yet. At least a half-written Japanese version of the book is available online for free (https://www.sigbus.info/compilerbook), and I'll probably translate this to English and share at least a few chapters for free. But nothing is set in stone yet. There's no mailing list for notifications yet.
Outstanding. A professional C compiler with a hackable codebase that emits x86_64 code. I'm noticing it assumes glibc-based linux. What if I modified it to emit Actually Portable Executables without needing ld/as?
>Each commit of this project corresponds to a section of the book. For this purpose, not only the final state of the project but each commit was carefully written with readability in mind. Readers should be able to learn how a C language feature can be implemented just by reading one or a few commits of this project. For example, this is how while, [], ?:, and thread-local variable are implemented. If you have plenty of spare time, it might be fun to read it from the first commit.
Is there any similar project like this where LLVM IR is used? I’ll start building a language just for fun during weekends and I plan to use LLVM but it is rather hard to understand clang on limited time, so a smaller scale project would be awesome.
I would look at the LLVM tutorials, and maybe the insides of your favourite languages compiler (other than clang)
When it comes to both parsing and emitting IR, keep it simple (stupid!) - the difficult bit (on a day to day basis) with the compiler is almost always the language semantics, the backend is more theory-dense but to just implement a language you can use LLVM as a black-box.
If you minimise mutable state and utilise lowering (you can implement foreach by lowering the AST to a for loop, for example) your compiler will be much easier to debug.
maybe the author can verify, from what I could see it generates assembler files that one should save to a .S file and then can be run with gcc's `cc -o executable file.S`.
It produces a .S file if `-S` flag was given. By default, it produces a .S file in a temporary and assemble it with `as` and write its output object file (an .o) file is produced as an output from the compiler.
Thant's great! Missing parts are assembler and linker, which of course are out of the scope of a C compiler per se, though make complete toolchain. I'm interested in this stuff because I'm toying with my own simple machine coined for tiny FPGAs and I concidered writing my own C compiler, but I need an assembler first.
It would be helpful if the title was edited to feature the compiler's name: chibicc. It would make it easier to search and SEO-wise it would be helpful to disseminate the project.
When I find a bug in this compiler, I go back to the original commit that introduced the bug and rewrite the commit history as if there were no such bug from the beginning. This is an unusual way of fixing bugs, but as a a part of a book, it is important to keep every commit bug-free.
Somehow I can't imagine Brian Kernighan or Dennis Ritchie making those sorts of commits.
I would imagine it is done to avoid having a chapter at the end showing all the patches and why they were needed. A compiler course shouldn't have a bunch of errors if they can be avoided.
I doubt Brian Kernighan or Dennis Ritchie put all the errata at the end of their books on subsequent printings. They fixed the main text.
> When I find a bug in this compiler, I go back to the original commit that introduced the bug and rewrite the commit history as if there were no such bug from the beginning. This is an unusual way of fixing bugs, but as a a part of a book, it is important to keep every commit bug-free.
Ooo la la! "Chibicc Vol. II, The Bugs" !?
In all seriousness, a book about the bugs would be (IMO) even more fun to read than the compiler book.