Potentially Discontinue C Transpilation #6
Labels
compatibility
OS- and compiler-dependent compatibilities
performance
Compiler performance improvements
Milestone
Currently, Cabin compiles to native by transpiling to C first and then compiling that to a native executable. This is a good quick-and-easy solution that works on pretty much all hardware. However, it comes with some drawbacks. For one, we are limited by compilation time — Cabin will always have a relatively slow compilation time because it has to compile to C first and then compile the C after that. Ideally, it'd be better to just have a one-step process.
There are many avenues to explore here. First, let's rule some out: Cabin will not be interpreted, nor will it run on a virtual machine. Both of these are huge performance knocks to the language, and we want to keep it very fast.
One option is to use LLVM, a popular choice for languages. LLVM is highly optimized and tried-and-tested as a robust framework. The biggest drawback with LLVM is that it's extremely complicated and poorly documented. Not only is this an issue for simply ease of implementation, but also it concerns maintainability. Avoiding LLVM has a number of benefits, such as some of the ones described in Zig's issue concerning moving away from LLVM. Other IR codegens like Cranelift are options too, which tend to be more simple but less performant than LLVM.
Another option is to transpile directly to native assembly, but this has the limitation that each individual architecture will need its own implementation, and we'll undoubtedly begin to introduce architecture-specific bugs.
There are other possibilities to consider, these are just some of them. Cabin could also just remain a C-transpiled language, if that is deemed best. It's just worth considering and finalizing what the compilation process will look like before 1.0.
The text was updated successfully, but these errors were encountered: