>supporting multiple codegen architectures
Shouldnt it be a result of modular software design?
>exposing the compiler as an API for external tooling
Isn't it just generating libraries instead of executables?
Shouldnt it be a result of modular software design?
>exposing the compiler as an API for external tooling
Isn't it just generating libraries instead of executables?
The LSP for Java [2] used in eg. VSCode’s Java plugins, builds on this API.
But, no, I haven’t seen a generalized approach to this architecture discussed in literature.
1: https://github.com/eclipse-jdt/eclipse.jdt.core 2: https://github.com/eclipse-jdtls/eclipse.jdt.ls
But it seems like you're just creating libs that everyone and embedd / use and that's it
e.g `auto ast = Compiler.GenerateAST(code);`
As far as I have done in the toy compilers and seen the things in actual production ready compilers, the codegen is still very much tied to the one thing or the other rest llvm.
There’s also a new experimental rewrite of the Nim compiler called Nimony which targets a new intermediate called NIFC. That is intended to the be transformed to C, LLVM, JavaScript, etc.
You want to generate e.g x86 + ARM + RISCV, yea?, and shouldnt it be a result of modular architecture?
like your various codegens just take your AST and generate output