[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-6226":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":19,"stars90d":16,"forks30d":16,"starsTrendScore":20,"compositeScore":21,"rankGlobal":10,"rankLanguage":10,"license":22,"archived":23,"fork":23,"defaultBranch":24,"hasWiki":25,"hasPages":23,"topics":26,"createdAt":10,"pushedAt":10,"updatedAt":27,"readmeContent":28,"aiSummary":29,"trendingCount":16,"starSnapshotCount":16,"syncStatus":17,"lastSyncTime":30,"discoverSource":31},6226,"chibicc","rui314\u002Fchibicc","rui314","A small C compiler","",null,"C",11684,1053,175,95,0,2,21,72,15,44.07,"MIT License",false,"main",true,[],"2026-06-12 02:01:17","# chibicc: A Small C Compiler\n\n(The old master has moved to\n[historical\u002Fold](https:\u002F\u002Fgithub.com\u002Frui314\u002Fchibicc\u002Ftree\u002Fhistorical\u002Fold)\nbranch. This is a new one uploaded in September 2020.)\n\nchibicc is yet another small C compiler that implements most C11\nfeatures. Even though it still probably falls into the \"toy compilers\"\ncategory just like other small compilers do, chibicc can compile\nseveral real-world programs, including [Git](https:\u002F\u002Fgit-scm.com\u002F),\n[SQLite](https:\u002F\u002Fsqlite.org),\n[libpng](http:\u002F\u002Fwww.libpng.org\u002Fpub\u002Fpng\u002Flibpng.html) and chibicc\nitself, without making modifications to the compiled programs.\nGenerated executables of these programs pass their corresponding test\nsuites. So, chibicc actually supports a wide variety of C11 features\nand is able to compile hundreds of thousands of lines of real-world C\ncode correctly.\n\nchibicc is developed as the reference implementation for a book I'm\ncurrently writing about the C compiler and the low-level programming.\nThe book covers the vast topic with an incremental approach; in the first\nchapter, readers will implement a \"compiler\" that accepts just a single\nnumber as a \"language\", which will then gain one feature at a time in each\nsection of the book until the language that the compiler accepts matches\nwhat the C11 spec specifies. I took this incremental approach from [the\npaper](http:\u002F\u002Fscheme2006.cs.uchicago.edu\u002F11-ghuloum.pdf) by Abdulaziz\nGhuloum.\n\nEach commit of this project corresponds to a section of the book. For this\npurpose, not only the final state of the project but each commit was\ncarefully written with readability in mind. Readers should be able to learn\nhow a C language feature can be implemented just by reading one or a few\ncommits of this project. For example, this is how\n[while](https:\u002F\u002Fgithub.com\u002Frui314\u002Fchibicc\u002Fcommit\u002F773115ab2a9c4b96f804311b95b20e9771f0190a),\n[[]](https:\u002F\u002Fgithub.com\u002Frui314\u002Fchibicc\u002Fcommit\u002F75fbd3dd6efde12eac8225d8b5723093836170a5),\n[?:](https:\u002F\u002Fgithub.com\u002Frui314\u002Fchibicc\u002Fcommit\u002F1d0e942fd567a35d296d0f10b7693e98b3dd037c),\nand [thread-local\nvariable](https:\u002F\u002Fgithub.com\u002Frui314\u002Fchibicc\u002Fcommit\u002F79644e54cc1805e54428cde68b20d6d493b76d34)\nare implemented. If you have plenty of spare time, it might be fun to read\nit from the [first\ncommit](https:\u002F\u002Fgithub.com\u002Frui314\u002Fchibicc\u002Fcommit\u002F0522e2d77e3ab82d3b80a5be8dbbdc8d4180561c).\n\nIf you like this project, please consider purchasing a copy of the book\nwhen it becomes available! 😀 I publish the source code here to give people\nearly access to it, because I was planing to do that anyway with a\npermissive open-source license after publishing the book. If I don't charge\nfor the source code, it doesn't make much sense to me to keep it private. I\nhope to publish the book in 2021.\nYou can sign up [here](https:\u002F\u002Fforms.gle\u002FsgrMWHGeGjeeEJcX7) to receive a\nnotification when a free chapter is available online or the book is published.\n\nI pronounce chibicc as _chee bee cee cee_. \"chibi\" means \"mini\" or\n\"small\" in Japanese. \"cc\" stands for C compiler.\n\n## Status\n\nchibicc supports almost all mandatory features and most optional\nfeatures of C11 as well as a few GCC language extensions.\n\nFeatures that are often missing in a small compiler but supported by\nchibicc include (but not limited to):\n\n- Preprocessor\n- float, double and long double (x87 80-bit floating point numbers)\n- Bit-fields\n- alloca()\n- Variable-length arrays\n- Compound literals\n- Thread-local variables\n- Atomic variables\n- Common symbols\n- Designated initializers\n- L, u, U and u8 string literals\n- Functions that take or return structs as values, as specified by the\n  x86-64 SystemV ABI\n\nchibicc does not support complex numbers, K&R-style function prototypes\nand GCC-style inline assembly. Digraphs and trigraphs are intentionally\nleft out.\n\nchibicc outputs a simple but nice error message when it finds an error in\nsource code.\n\nThere's no optimization pass. chibicc emits terrible code which is probably\ntwice or more slower than GCC's output. I have a plan to add an\noptimization pass once the frontend is done.\n\nI'm using Ubuntu 20.04 for x86-64 as a development platform. I made a\nfew small changes so that chibicc works on Ubuntu 18.04, Fedora 32 and\nGentoo 2.6, but portability is not my goal at this moment. It may or\nmay not work on systems other than Ubuntu 20.04.\n\n## Internals\n\nchibicc consists of the following stages:\n\n- Tokenize: A tokenizer takes a string as an input, breaks it into a list\n  of tokens and returns them.\n\n- Preprocess: A preprocessor takes as an input a list of tokens and output\n  a new list of macro-expanded tokens. It interprets preprocessor\n  directives while expanding macros.\n\n- Parse: A recursive descendent parser constructs abstract syntax trees\n  from the output of the preprocessor. It also adds a type to each AST\n  node.\n\n- Codegen: A code generator emits an assembly text for given AST nodes.\n\n## Contributing\n\nWhen I find a bug in this compiler, I go back to the original commit that\nintroduced the bug and rewrite the commit history as if there were no such\nbug from the beginning. This is an unusual way of fixing bugs, but as a\npart of a book, it is important to keep every commit bug-free.\n\nThus, I do not take pull requests in this repo. You can send me a pull\nrequest if you find a bug, but it is very likely that I will read your\npatch and then apply that to my previous commits by rewriting history. I'll\ncredit your name somewhere, but your changes will be rewritten by me before\nsubmitted to this repository.\n\nAlso, please assume that I will occasionally force-push my local repository\nto this public one to rewrite history. If you clone this project and make\nlocal commits on top of it, your changes will have to be rebased by hand\nwhen I force-push new commits.\n\n## Design principles\n\nchibicc's core value is its simplicity and the reability of its source\ncode. To achieve this goal, I was careful not to be too clever when\nwriting code. Let me explain what that means.\n\nOftentimes, as you get used to the code base, you are tempted to\n_improve_ the code using more abstractions and clever tricks.\nBut that kind of _improvements_ don't always improve readability for\nfirst-time readers and can actually hurts it. I tried to avoid the\npitfall as much as possible. I wrote this code not for me but for\nfirst-time readers.\n\nIf you take a look at the source code, you'll find a couple of\ndumb-looking pieces of code. These are written intentionally that way\n(but at some places I might be actually missing something,\nthough). Here is a few notable examples:\n\n- The recursive descendent parser contains many similar-looking functions\n  for similar-looking generative grammar rules. You might be tempted\n  to _improve_ it to reduce the duplication using higher-order functions\n  or macros, but I thought that that's too complicated. It's better to\n  allow small duplications instead.\n\n- chibicc doesn't try too hard to save memory. An entire input source\n  file is read to memory first before the tokenizer kicks in, for example.\n\n- Slow algorithms are fine if we know that n isn't too big.\n  For example, we use a linked list as a set in the preprocessor, so\n  the membership check takes O(n) where n is the size of the set.  But\n  that's fine because we know n is usually very small.\n  And even if n can be very big, I stick with a simple slow algorithm\n  until it is proved by benchmarks that that's a bottleneck.\n\n- Each AST node type uses only a few members of the `Node` struct members.\n  Other unused `Node` members are just a waste of memory at runtime.\n  We could save memory using unions, but I decided to simply put everything\n  in the same struct instead. I believe the inefficiency is negligible.\n  Even if it matters, we can always change the code to use unions\n  at any time. I wanted to avoid premature optimization.\n\n- chibicc always allocates heap memory using `calloc`, which is a\n  variant of `malloc` that clears memory with zero. `calloc` is\n  slightly slower than `malloc`, but that should be neligible.\n\n- Last but not least, chibicc allocates memory using `calloc` but never\n  calls `free`. Allocated heap memory is not freed until the process exits.\n  I'm sure that this memory management policy (or lack thereof) looks\n  very odd, but it makes sense for short-lived programs such as compilers.\n  DMD, a compiler for the D programming language, uses the same memory\n  management scheme for the same reason, for example [1].\n\n## About the Author\n\nI'm Rui Ueyama. I'm the creator of [8cc](https:\u002F\u002Fgithub.com\u002Frui314\u002F8cc),\nwhich is a hobby C compiler, and also the original creator of the current\nversion of [LLVM lld](https:\u002F\u002Flld.llvm.org) linker, which is a\nproduction-quality linker used by various operating systems and large-scale\nbuild systems.\n\n## References\n\n- [tcc](https:\u002F\u002Fbellard.org\u002Ftcc\u002F): A small C compiler written by Fabrice\n  Bellard. I learned a lot from this compiler, but the design of tcc and\n  chibicc are different. In particular, tcc is a one-pass compiler, while\n  chibicc is a multi-pass one.\n\n- [lcc](https:\u002F\u002Fgithub.com\u002Fdrh\u002Flcc): Another small C compiler. The creators\n  wrote a [book](https:\u002F\u002Fsites.google.com\u002Fsite\u002Flccretargetablecompiler\u002F)\n  about the internals of lcc, which I found a good resource to see how a\n  compiler is implemented.\n\n- [An Incremental Approach to Compiler\n  Construction](http:\u002F\u002Fscheme2006.cs.uchicago.edu\u002F11-ghuloum.pdf)\n\n- [Rob Pike's 5 Rules of Programming](https:\u002F\u002Fusers.ece.utexas.edu\u002F~adnan\u002Fpike.html)\n\n[1] https:\u002F\u002Fwww.drdobbs.com\u002Fcpp\u002Fincreasing-compiler-speed-by-over-75\u002F240158941\n\n> DMD does memory allocation in a bit of a sneaky way. Since compilers\n> are short-lived programs, and speed is of the essence, DMD just\n> mallocs away, and never frees.\n","chibicc 是一个小型的 C 语言编译器，实现了大部分 C11 标准的功能。该项目采用 C 语言编写，虽然被归类为“玩具编译器”，但 chibicc 能够成功编译 Git、SQLite 和 libpng 等实际项目，并且生成的可执行文件能通过这些项目的测试套件。这表明 chibicc 支持广泛的 C11 特性并能够正确处理数十万行的实际 C 代码。此外，chibicc 的开发还作为一本关于 C 编译器和底层编程书籍的参考实现，该书通过逐步增加功能的方式介绍如何从零开始构建一个完整的 C 语言编译器。因此，chibicc 非常适合用于教育场景中学习编译原理以及 C 语言的内部机制。","2026-06-11 03:05:59","top_language"]