(Totally unrelated to the original post, but hey, we've already left that path, so why not?)
Speaking of the Plan 9 toolchain, I much prefer the way it works internally compared to the Go toolchain because it is much easier to re-target. I haven't ported the Plan 9 toolchain (only saw Charles do it), but I did port the Go toolchain twice, once for arm64, and once for sparc64; once in C, and once in Go. In Plan 9 porting is easy because the assembler, the compiler, and the loader are all separate programs. Apart from trivial things like a.out.h, they are completely independent. One could work on them in any order. Better yet, the compiler can generate object files before the loader is ready, and when the loader is finally ready, it can just consume these already-produced object files. Alternativelly, one can have the assembler ready very quickly, and write enough of a libc so he can test the compiler when that is written. In Go it's not like this. The assembler, compiler, and linker all link against a library which does roughly what the Plan 9 loader does. This means that you have to have this working in some capacity before you can start the other programs. But this library is very hard to test since you don't have an assembler yet. Even worse, once you wrote enough of this library to have the assembler and compiler produce some kind of output, you still can't test anything because you need a runtime. But the runtime is written in Go, so now you have to write large quantities of Go and tricky assembly, without having the possibilty to test anything, and while using a broken compiler (since the compiler has not ran a single program yet, it's bound to be broken). This tightly-coupled design makes development very difficult. Having it done twice (actually three times), I'd say it's about 7x-10x more work to re-target the Go toolchain than it is to re-target the Plan 9 toolchain. Mind you, compared to gcc and clang, 7x-10x more work is still pretty good... -- Aram Hăvărneanu
