Re: [9fans] Go/Inferno toolchain (Was: comment and newline in

[Russ Cox <rsc@swtch.com>]

what i said to people at usenix was approximately
the following.

i think that porting go to plan 9 - the time to get
something working that runs all the go programs -
is not more than a week of concerted effort.
i also think that it just hasn't been high enough
priority for anyone (myself included) to put that
amount of effort in.

the go runtime sets up the segment registers,
with the operating system's help, so that gs
points at per-kernel-thread storage.
the linker generates references through gs
for the pseudo-addressing mode 0(gs), 4(gs), etc.
on plan 9 there is already per-kernel-thread
storage: it is called the stack.  the workaround
would be for the linker to know the top of stack
address and rewrite 0(gs) and 4(gs) to fixed
memory addresses just below the top of the stack.
it would be just as efficient as the 0(gs), 4(gs)
stuff and not require any kernel changes.

the build uses make, yes, and in some places
there are even include files that include other
include files (gasp!), but writing equivalent mkfiles
should take not very much time.  we're not doing
anything magical, and the particular style in the
makefiles should be familiar.

there's obviously a lot of divergence between
the plan 9 tool chain and the go tool chain.
the object files have different format, and so on.
to get off the ground i would suggest treating
the go copies of the tools as separate programs
and libraries from the originals.  for example,
you might install the go libmach as /386/lib/go/libmach.a
and the compiler tool chain as /386/bin/go/8a,
/386/bin/go/8c, /386/bin/go/8g, /386/bin/go/8l.
the .8 files created by those tools would not
be compatible with the standard ones, and the
standard nm wouldn't understand the final 8.out,
but the final 8.out would run.  you'd have to
disable the runtime copy of the symbol table
(the "nacl" target in 8l already does).
anyway, keep everything separate and get it
working.  once you have a working system then
you could worry about reconciling the two worlds
to whatever extent is appropriate.

i think people get too hung up on trying to make
the port back perfect.  just make it work.
then make it better.

russ