I wrote 'multiple codegen architectures' instead of 'multiple architectures for codegen'.

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.

Nim has multiple backends and is relatively mature. It’s fairly readable as compilers go.

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.

>I wrote 'multiple codegen architectures' instead of 'multiple architectures for codegen'.

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

Making the _compiler itself_ provide an API enables things like LSP, which don't want to generate machine code at all. A traditional single-pass compiler usually can't accommodate this without re-plumbing.

The Eclipse Compiler for Java [1] is a notable exception, architected around incremental compilation, an API for “live” AST manipulation, and a layered non-batch approach to when to invoke various analysis steps.

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

I'm aware, I've used C#/.NET Compiler ecosystem and their Compiler as a Service approach

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);`