Honestly, if you're going to build a compiler today, an LLM is a pretty good way to go about it. Just make sure you actually design the language and let the LLM do the implementation and testing.
xc[1] started off as a modern compiler for the 6502. It's since developed into a cross-platform (runs on arm A9 on a zynq, on Mac M-series, on Windows (64-bit) and Linux (same, 64-bit). Each platform can produce code for any of {6502, m68k, Arm A9, Apple M-series, Windows x86_64, Linux x86_64, or WASM32).
It's relatively modern - uses ARC to manage memory, classes, protocols, has bound-functions and blocks, can #use <shared-library> and automatically extract the methods, functions, types etc. from the DWARF sections within, which makes binding to C libraries trivial, and compiles to comparable-to-clang efficient code. Most of the time clang still wins, but only by a factor of 1.x, sometimes xc wins :)
There's even a (somewhat less advanced) UI framework modelled after AppKit, so you can create a TableView, give it a delegate/datasource, and you get a scrolling table-view UI on any platform.
I did all the language design and since I liked ObjC it's heavily influenced by that (without all the brackets..), Claude did all the compiling and testing. There were plenty of times I redirected Claude to where I wanted to go, not where it went by default - sometimes I'd characterise the LLM as "lazy", which is kind of weird in itself. I always like to do it "right", not "good enough"...
I'm pretty happy with it. Having the same code being able to emit x86_64 binaries and WASM32 made writing blewit [2] much easier - the server and the client both use the same rendering classes (when WASM isn't available, the server renders).
Honestly, if you're going to build a compiler today, an LLM is a pretty good way to go about it. Just make sure you actually design the language and let the LLM do the implementation and testing.
xc[1] started off as a modern compiler for the 6502. It's since developed into a cross-platform (runs on arm A9 on a zynq, on Mac M-series, on Windows (64-bit) and Linux (same, 64-bit). Each platform can produce code for any of {6502, m68k, Arm A9, Apple M-series, Windows x86_64, Linux x86_64, or WASM32).
It's relatively modern - uses ARC to manage memory, classes, protocols, has bound-functions and blocks, can #use <shared-library> and automatically extract the methods, functions, types etc. from the DWARF sections within, which makes binding to C libraries trivial, and compiles to comparable-to-clang efficient code. Most of the time clang still wins, but only by a factor of 1.x, sometimes xc wins :)
There's even a (somewhat less advanced) UI framework modelled after AppKit, so you can create a TableView, give it a delegate/datasource, and you get a scrolling table-view UI on any platform.
I did all the language design and since I liked ObjC it's heavily influenced by that (without all the brackets..), Claude did all the compiling and testing. There were plenty of times I redirected Claude to where I wanted to go, not where it went by default - sometimes I'd characterise the LLM as "lazy", which is kind of weird in itself. I always like to do it "right", not "good enough"...
I'm pretty happy with it. Having the same code being able to emit x86_64 binaries and WASM32 made writing blewit [2] much easier - the server and the client both use the same rendering classes (when WASM isn't available, the server renders).
1: https://atari-xt.com/compiler/
2: https://blewit.uk/