fuhsnn
commented
1 day ago If the goal is still targeting shecc, I strongly recommend developing a textual language or an API that build the IR directly.
The way C works wasn't designed to be information-preserving. Macros, C99
Everybody is writing their own C compilers these days, thanks to recent publication of Nora Sandler's book and projects like chibicc and acwj, on Github there are hundreds of "C compiler"s with weekly activity, but I'm not aware of a small optimizing backend that targets 32-bit Raspberry Pi. The current popular projects in small-backend space are Cranelift and QBE, the former is not designed for system programming with C-ABI, and the latter only supports 64-bits and have no assembler, so even in terms of "business strategy" I believe there is broader opportunity for shecc's backend to stand out if it "opens up" with IR generation interface.
Another way to put it, if going forward the generate/consume C route, we'll be doing frustrating workarounds for the unfortunate combination of a limited C-frontend targeting a limited C-backend, that is just, not fun. However, if we can "step up a bit" to go the IR route, shecc can be a more versatile backend with new users/contributors and collaboration opportunities on both the frontend and backend side, (NCKU should have some students interested in PL or MCU design, right?), and slimcc can be a simple-to-read example for targeting the IR.
Does this sound like a good suggestion to you?
Original idea was brought by LLVM-CBE (this one is ressurected by Julia), allows intermediate form of C code (IR, AST, etc.) being converted and generated as C code. This is practically useful when other toolchain / projects requires a complete C frontend. By having a C backend, we can retreive a preprocessed and optimized[^1] C source file, with every tricky C frontend mechanism being resolved and organized by slimcc, header and macro for example.
I have attempted to create a usable C backend in my own fork. However, current IR is heavily designed for assembly code generation, and cannot be served as AST completely, which causes some critical information lost in the process, e.g. function prototype is later being replaced by a definition.
It would be best if slimcc have a proper AST, for not only C backend but also other potential assembly backends.
This idea is brought by @jserv which is previously introduced in #89.
[^1]: Optimizations provided by slimcc, contant folding for example.