The Go assembly language is actually one of the things that make doing something like this difficult.

Go uses the Plan9 assembly syntax but doesn't support GNU asm syntax. gccgo uses GNU asm syntax but doesn't support Plan9 assembly.

The Go linker doesn't allow you to not link in the Go standard library runtime, which means you need to use gccgo to write a kernel.

The end result is that you can't do something that's buildable with the standard Go toolchain, and even if Go were to add a "don't link the runtime" option there'd be no way to incrementally port your ASM over one bit at a time. It's all or nothing.

I take a slightly different approach for my implementation that allows me to use the standard go toolchain. I use nasm for the early ASM code and patch the go build tool's output (see: https://github.com/achilleasa/gopher-os/blob/master/Makefile...) to bypass the link step and replace it with a manual call to ld that links the go object files with the output from nasm.

I will be talking about this approach in more detail in GolangUK '17.

> I will be talking about this approach in more detail in GolangUK '17.

Sounds great. Any chance for you to come to dotgo.eu?

Do you know if your talk going to be online afterwards?

Yes, the talk will be recorded and posted online with the slides and some getting started code.

Just like C in the 80's and 90's, and it wasn't a problem for its adoption.