I always wonder why you would target another language with your compiler, instead of an IR.
What is the benefit of transpiling to C++ over using LLVM?
(not meant as a criticism, genuinely curious)
What is the benefit of transpiling to C++ over using LLVM?
(not meant as a criticism, genuinely curious)
However I would advise to target an IR instead.
Doesn't need to be LLVM, if the purpose is only learning about compilers, do as follows:
1 - Create an IR, preferably stack based as they are quite easy to target
2 - Basic IR interpreter for testing the workflow
3 - With a macro assembler, convert the IR into machine code in a dumb way
Now you have a workable compiler, even if it won't win any prizes.
If still interesting, then proceed to improve the code generation in a proper way.
https://github.com/udem-dlteam/ribbit
https://www.iro.umontreal.ca/~feeley/papers/YvonFeeleyVMIL21...
Kind of high level Assembly like language used across compiler stages to make them more modular and easier to manipulate.
Some known examples are LLVM bitcode, GCC GIMPLE, Rust MIR, Swift SIR, Tensorflow MIR,....
Even bytecode formats like MSIL, JVM, WASM, P-Code,.... can be considered some form of IR.
1. The chip isn't supported by LLVM (which most new languages use)
2. The platform owner /requires/ the use of their C++ only SDK and will not approve any other compilers for use on their app store, so C++ becomes the "machine language" of that platform.
Some people may do it because it's more approachable to them (and/or others). Others may have language models/runtimes that align closely with the target language. Or they may want to "stand on the shoulders of giants", benefiting from the higher-level optimizations of the target language. Also, for example, LLVM still doesn't target as many architectures as gcc (though I'm not saying that's necessarily very relevant for most users).
That's just what comes to mind. I can't say for certain anything about this particular language though!
And third and less important you can add more expensive offline optimizations, which are too heavy at run-time. Like escape analysis, and inlining.
Esp for the static parts. The dynamic parts just call into the shared ruby runtime.
Compiling to an IR doesn't mean 'and then interpret or JIT it'. Can can use an IR to compile to native. GCC, Clang, Rust etc all an IR, for example.