4 ms·

You can write an operating system in a garbage collected language. One example, Oberon System: https://en.wikipedia.org/wiki/Oberon_(operating_system) https://

You can write an operating system in a garbage collected language. One example, Oberon System: https://en.wikipedia.org/wiki/Oberon_(operating_system) https://en.wikipedia.org/wiki/Oberon_(operating_system) I don't know anyone who has written more than a toy OS in Go, but it does not seem a fundamentally impossible task. Getting started is harder, because the earliest parts of the kernel would be modifications to the runtime package. Once you get that out of the way, writing drivers could be quite fun. But to the broader topic, I don't have a good definition of "systems language" so I'm not going to claim Go is one. (I work on Go.)

JoeAltmaier 11y ago
An OS often has to generate nearly every opcode on the target machine (many are there just for this purpose). Can Go generate arbitrary ASM instructions? An OS has to deal with often strange calling conventions (interrupt routines, OS entry point traps, multiple language support). Can Go express the calling stack in any way? Drivers are often interested in controlling timing and latency down to the instruction. Can generated Go code be examined by the developer for instruction counts? A good kernel language is pretty low-level. Used to write them all in assembler.
- crawshaw 11y ago
  Go has an assembler: https://golang.org/doc/asm https://golang.org/doc/asm I have used it in sticky situations, like the trampoline for a signal handler, and writing functions that have to conform to a C ABI because they are called by the OS. (In particular, a loader .init function.) To minimize how much assembly a theoretical OS author has to write, there are a couple of extra tricks in the runtime package they could borrow, like //go:noescape annotations. You have to be careful when writing code like that, but it does the job. Before the Go runtime was rewritten in Go, I worried that for a task like writing a kernel there would be a lot of assembly. But I have been pleasantly surprised by how little is needed in the runtime, and that gives me some hope for a project like that. Of course this is speculation on my part, I could be wrong.
nindalf 11y ago
Hi crawshaw, thanks for your work on Go in general and smaller binary sizes in particular. Could you explain why cmd/go generated by Go tip remains larger than the one generated by Go 1.4.3?
- crawshaw 11y ago
  My guess is that Dave Cheney is measuring the cmd/go that comes with the release, meaning it's a different program each time it is measured. Someone probably snuck some new features into it between releases. :-) Like all the -buildmode support for shared libraries, building .so files to load from C programs, etc. I have been using it in my binary size measurements as I work on http://golang.org/issue/6853 http://golang.org/issue/6853, and it has shrunk reasonably well since the 1.6 release. More to come!

JoeAltmaier 11y ago

An OS often has to generate nearly every opcode on the target machine (many are there just for this purpose). Can Go generate arbitrary ASM instructions? An OS has to deal with often strange calling conventions (interrupt routines, OS entry point traps, multiple language support). Can Go express the calling stack in any way? Drivers are often interested in controlling timing and latency down to the instruction. Can generated Go code be examined by the developer for instruction counts? A good kernel language is pretty low-level. Used to write them all in assembler.

crawshaw 11y ago
Go has an assembler: https://golang.org/doc/asm https://golang.org/doc/asm I have used it in sticky situations, like the trampoline for a signal handler, and writing functions that have to conform to a C ABI because they are called by the OS. (In particular, a loader .init function.) To minimize how much assembly a theoretical OS author has to write, there are a couple of extra tricks in the runtime package they could borrow, like //go:noescape annotations. You have to be careful when writing code like that, but it does the job. Before the Go runtime was rewritten in Go, I worried that for a task like writing a kernel there would be a lot of assembly. But I have been pleasantly surprised by how little is needed in the runtime, and that gives me some hope for a project like that. Of course this is speculation on my part, I could be wrong.

nindalf 11y ago

Hi crawshaw, thanks for your work on Go in general and smaller binary sizes in particular. Could you explain why cmd/go generated by Go tip remains larger than the one generated by Go 1.4.3?

crawshaw 11y ago
My guess is that Dave Cheney is measuring the cmd/go that comes with the release, meaning it's a different program each time it is measured. Someone probably snuck some new features into it between releases. :-) Like all the -buildmode support for shared libraries, building .so files to load from C programs, etc. I have been using it in my binary size measurements as I work on http://golang.org/issue/6853 http://golang.org/issue/6853, and it has shrunk reasonably well since the 1.6 release. More to come!