The ABI (all registers caller-saved, parameters and return values unconditionally passed on the stack) is quite simple compared to C. Is it still in flux, or is it considered done?<p>Of course the Go team is aware of this, but once you support dynamic linking, ABIs become very hard to change. A bad one will weigh you down for a long time! Apple famously used PC-relative addressing on PowerPC, which has no program counter register. It was, let's say, measurably suboptimal, but they were stuck with it until the Intel transition (or technically the PPC64 one).
The ABI seems to sacrifice performance for the sake of simplicity, which IMHO has little value at such a low level. There's a reason why the x86-64 ABI passes 6 (4 for the MS variant) machine words via registers! Disappointing.<p>Both D and Go use an unusual convention. The GCC maintainers raised issues over D's ABI during discussions regarding integrating the GCC-based D compiler. I wonder how did this apply to Go's inclusion? Or did GCC support the Plan9 ABI before Go's inclusion?
The author next a small comment that dynamic linking will be making its way into Go sometime soon. Right now, with go being fully staticly link you always know all of the code that you link against, making it easier to dive into. Does anyone know what the Golang team is thinking about when it comes to dynamic linking?
A few small nits:<p>The Go calling convention is described correctly, but the runtime is largely C (compiled by a modified Plan 9 C compiler), and C compilers return values in a register, not on the stack.<p>The Plan 9 ABI is significantly different. Yes, the compilers come from Plan 9 (Inferno, actually), but the calling convention was modified. E.g. on Plan 9 first argument is usually passed in register.