It’s been a long time coming, but I’m now starting to put together pieces of the llgo runtime. Don’t expect much any time soon, but I am zeroing in on a design at least. The sleuths in the crowd will find that only string concatenation has been implemented thus far, which is pretty boring. Next up, I hope, will be interface-to-interface conversions, and interface-to-value conversions, both of which require (for a sane implementation) a runtime library.
I had previously intended to write the runtime largely in C, as I expected that would be the easiest route. I started down this road writing a basic thread creation routine using pthread, written in C. The code was compiled using Clang, emitting LLVM IR which could be easily linked with the code generated by llgo. It’s more or less the same idea implemented by the gc Go compiler (linking C and Go code, not relying on pthread). Even so, I’d like to write the runtime in Go as much as possible.
Why write the runtime in Go? Well for one, it will make llgo much more self contained, which will make distribution much easier since there won’t be a reliance on Clang. Another reason is based on a lofty, but absolutely necessary goal: that llgo will one day be able to compile itself. If llgo compiles itself, and compiles its own runtime, then we have a great target for compiler optimisations: the compiler itself. In other words, “compiler optimisations should pay for themselves.”
In my last post I mentioned that LLVM 3.1 is coming up fast, and this release has the changes required by llgo. Unfortunately, I’ve just found that the C API lacks an interface for linking modules, so I’m going to have to submit a patch to LLVM again, and the window for inclusion in 3.1 has certainly passed. Rather than break gollvm/llgo’s trunk again, I’ll create a branch for work on the runtime. I’ll post again when I’ve submitted a patch to LLVM, assuming the minor addition is accepted.