Re: [9fans] FP register usage in Plan9 assembler

["Aram Hăvărneanu" <aram.h@mgk.ro>]

(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