That’s like… It’s purpose. Compilers always have a frontend and a backend. Even when the compiler is entirely made from scratch (like Java or go), it is split between front and backend, that’s just how they are made.
So it makes sense to invest in just a few highly advanced backends (llvm, gcc, msvc) and then just build frontends for those. Most projects choose llvm because, unlike the others, it was purpose built to be a common ground, but it’s not a rule. For example, there is an in-developement rust frontend for GCC.
Can confirm, even the little training compiler we made at Uni for a subset of Java (Javali) had a backend and frontend.
I can’t imagine trying to spit out machine code while parsing the input without an intermediary AST stage. It was complicated enough with the proper split.
I have built single pass compilers that do everything in one shot without an AST. You are not going to get great error messages or optimization though.
That’s like… It’s purpose. Compilers always have a frontend and a backend. Even when the compiler is entirely made from scratch (like Java or go), it is split between front and backend, that’s just how they are made.
So it makes sense to invest in just a few highly advanced backends (llvm, gcc, msvc) and then just build frontends for those. Most projects choose llvm because, unlike the others, it was purpose built to be a common ground, but it’s not a rule. For example, there is an in-developement rust frontend for GCC.
Can confirm, even the little training compiler we made at Uni for a subset of Java (Javali) had a backend and frontend.
I can’t imagine trying to spit out machine code while parsing the input without an intermediary AST stage. It was complicated enough with the proper split.
I have built single pass compilers that do everything in one shot without an AST. You are not going to get great error messages or optimization though.
I can imagine;