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?
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.
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.
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.
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.
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.
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.
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 :)
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.
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.
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.
Looking forward to the release, and will definitely get a copy!
Another small C compiler by the same author: https://github.com/rui314/8cc
ELVM uses a modified version of 8cc to compile C into some utterly weird targets. Brainfuck, sed, TeX, whitespace...
https://github.com/shinh/elvm
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?
Do it and I'll use it
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.
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.
Send an email to the mods hn@ycombinator.com They sometimes makes these changes.
Added. Thanks!
Where will we be able to buy a copy? Is there a mailing list? I will certainly forget about this book in n months time.
You could write to the author or follow their social media: https://www.sigbus.info/
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.
Related discussions on Reddit:
https://www.reddit.com/r/programming/comments/j35w0i/im_writ...
https://www.reddit.com/r/C_Programming/comments/j2wjyp/chibi...
https://www.reddit.com/r/Compilers/comments/j2py9x/im_writin...
nice
What a great resource. I will certainly pick up the book when it’s out.
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.
For a different optimizing C compiler that is also small, and usable as a JIT see MIR project by Vladimir Makarov - https://github.com/vnmakarov/mir/tree/master/c2mir
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.
https://bellard.org/tcc/
Probably best know and with loooong beard...
My immediate thought given title
https://en.m.wikipedia.org/wiki/Small-C
This is what I think of when I see Small C as a proper noun.
Me too. Taught myself C with that!
This generation, CPM support and everything: https://archive.org/details/dr_dobbs_journal_vol_09/page/n33...
Me as well, that was my introduction to C, before I eventually had access to Turbo C 2.0 for MS-DOS.
I love 'the incremental approach to compiler construction'. Here are a few other courses that use this approach to teach compiler construction:
* http://www.ccs.neu.edu/course/cs4410/
* https://ucsd-cse131-f19.github.io/
* https://jeapostrophe.github.io/courses/2017/spring/406/notes...
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.
[1] https://turingcomplete.fm/
Looks like it's a Japanese podcast? Or is there an English version?
Oh, yes the podcast is only in Japanese.
Hard to tell. Maybe some die hard fan could shed some light
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 :)
Nothing in particular has happened to me, but producing a high quality podcast episodes takes time, and I didn't have enough time for doing that.
Oh I see, thank you for your response. I'm glad that you intend to continue the podcast, can't wait for the next episode :)
Can it compile itself ?
Yes, it is.
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.
This looks great, I’ll definitely use it.
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 used LLVM for a small compiler; not for C, but for a Java-like language: https://github.com/LucianoLaratelli/dj2ll-public All the API calls are contained within codegen.cpp.
The Kaleidoscope LLVM tutorial!
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.
I wonder how it does with Csmith.
Awesome project!
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.
I would read that book.
Relevant: Knuth's paper "The Errors of TeX"
https://yurichev.com/mirrors/knuth1989.pdf