OSDev.org

Hi guys!
It's been sooooo long that I haven't been here on OSdev. I'm glad to see people like JamesM, Solar, Brendan... still alive and active However, it's sad to say that all my experiences on OS development is gone. So it's much like a fresh (re)start.
Okay, back to the topic. As you may know, Golang from Google officially reached release 1 a few days ago. And it is a really interesting language. So, I started to ask myself is it possible to use it for OS dev, and how it could be done. It is garbage-collected, compiled language that packs everything (yes, including standard libs) in one executable.

Ideas?

EDIT: one more note, Go defines itself as "low-level language" with pointer support, but no pointer arithmetics.
EDIT2: GCC has an implementation of Go, which doesn't have garbage collection as far as I know.

I doubt it would be possible without some very serious hacking. You would absolutely have to force the compiler not to generate any code that required the Go library, which would probably prove very difficult. Even setting up a language as close to bare metal C as C++ is far from trivial (setting it up the correct way that it is). I couldn't figure out if you could cast a integer type variable to a pointer, but if not, that would, for all intents and purposes, mean no it couldn't be used to write a kernel by itself. But according to the FAQ, you can link Go programs with C functions "carefully", so you could write some C stubs that do this stuff like this for you. This would be highly inefficient though.

I also would most definitely not classify Go as in the same arena as C. I wont go as far as saying it isn't a low level language, as that would depend on the definition of low level, which is highly subjective. With C99, you have nothing syntactically that was OS dependent. E.g. any valid C program that doesn't depend on the C library headers will run fine in a kernel like environment (bare metal). But even with languages like C++, with the new operator, you don't have to drag any headers\imports into the fray without mixing in the library as well.

Even IF it were possible, I see no reason as to why you would even want to.

Go's Homepage wrote:Go is an open source programming environment that makes it easy to build simple, reliable, and efficient software.

That pretty much the "mission statement" of the Go language. Obviously thing's like "easy" and "simple" don't really belong in something like kernel development. Languages like Go are usually designed with as many convenient abstractions as possible. In terms of kernel development, most languages's "conveniences" turn into nuisances, everyone of which are reasons not to use said language.

1. Why would I want to use Go?
Answer: It's more like a fun experiment, and probably a proof of concept, rather than a serious project. And the plus of using Go is that it is simple and easy to verify, creating an OS running single address space, everything at ring 0 (somewhat similar to those managed language OSes)

2. Provide a runtime?
Answer: This is the part that I'm not sure about, and need input from you guys. So far, my plan is to take a look into Go compiler's source code and see how I can modify it. This is because most of the runtime support is in there. Then maybe write a thin C layer to support multitasking, GUI, drivers, etc.

quanganht wrote:1. Why would I want to use Go?
Answer: It's more like a fun experiment, and probably a proof of concept, rather than a serious project. And the plus of using Go is that it is simple and easy to verify, creating an OS running single address space, everything at ring 0 (somewhat similar to those managed language OSes)

2. Provide a runtime?
Answer: This is the part that I'm not sure about, and need input from you guys. So far, my plan is to take a look into Go compiler's source code and see how I can modify it. This is because most of the runtime support is in there. Then maybe write a thin C layer to support multitasking, GUI, drivers, etc.

Why not take the "hack it and see" approach of compiling a do-nothing module, and seeing what the resulting ELF file requires from the runtime? you can start from there, and as you use more features you should see undefined symbols for runtime requirements.

quanganht it is very possible, but does require a not so small amount of preliminary work. If you have never done OS development before then I recommend also build a toy kernel in C while you developing your Go kernel. There are many amazing tutorials online so make sure you spend just as much time reading as you do coding. To start you will need at least: a bootloader, a machine emulator, and a cross-compiler. It is worth while trying to make your own bootloader, but if you are feeling lazy just grab one of the samples on osdev. The machine emulator I definitely recommend bochs... mainly because most of the tutorials you will find online do their testing in bochs. The cross-compiler will be your biggest headache I recommend checking out https://github.com/davecheney/golang-crosscompile and then read up on the gcc cross compiler (http://wiki.osdev.org/GCC_Cross-Compiler). Remember gcc does support Go1

Rudster816 I was very disappointed with your post. You seem pretty misinformed as to the nature of the Go programming language, and what's worse is you seemed more concerned with shooting down quanganht's idea then with trying to answer the question. Below are some of my comments regarding your response:

I couldn't figure out if you could cast a integer type variable to a pointer

Yes you can, check out the unsafe package in the standard library. That being said just as C can directly invoke assembly functions so too can Go. Here is an excellent thread on the topic: http://stackoverflow.com/questions/2951 ... le-go-code

you can link Go programs with C functions "carefully", so you could write some C stubs that do this stuff like this for you.

This is for linking against already created C programs until you can implement the functionality in Go. Since the point is for him to develop his own kernel there is no benefit here. There is no functionality available in C that is not available in Go. That being said if he does choose to link against C code there is absolutely no performance hit and I see no reason why you state it would be inefficient.

I also would most definitely not classify Go as in the same arena as C. I wont go as far as saying it isn't a low level language, as that would depend on the definition of low level, which is highly subjective.

Go is in exactly the same boat as C/C++ in terms of language level. The only argument that one might attempt posing is that it is garbage collected, but even this argument quickly fails with just a small amount of reading on the subject and looking at any of the "low level" functional programming languages.

With C99, you have nothing syntactically that was OS dependent. E.g. any valid C program that doesn't depend on the C library headers will run fine in a kernel like environment (bare metal). But even with languages like C++, with the new operator, you don't have to drag any headers\imports into the fray without mixing in the library as well.

Go is in exactly the same boat. There are two points to be aware of: a) You cannot use any code that links against the os package. b) Go routines cannot be used until you develop your own os library.

Go is an open source programming environment that makes it easy to build simple, reliable, and efficient software.

It is true that this is the new language description, but it is worth noting that this is a change. The original language description was: "Go is an agent oriented, concurrent, systems programming language". It's mission is to develop servers and systems software, and while they have no plans for developing an operating system, Rob Pike has often stated that Go would be a great language for developing operating systems and compilers.

Obviously thing's like "easy" and "simple" don't really belong in something like kernel development.

You are completely clouding the context in which "easy" and "simple" were being used. The team is referring to the ease of knowing what your code does because you only have to consider the code you are looking at. Nothing is hidden, compile times are fast, cyclic dependancies don't exist, and they enforce understanding in the rules of the language.. such as public identifiers must be capitalized.

In terms of kernel development, most languages's "conveniences" turn into nuisances

I would love to see this backed up with an example, because it seems like you are trying to generalize to the point of asserting a new truth.

I'm not familar with Go but:

fedler wrote:That being said if he does choose to link against C code there is absolutely no performance hit and I see no reason why you state it would be inefficient.

Go uses and ABI that is incompatible with C, so if anyone link Go against C code there will be some conversion involved. Furthermore, the lack of compiler intrinsics and inline assembly make it difficult or inefficient to implement some algorithms.

fedler wrote:There are two points to be aware of: a) You cannot use any code that links against the os package. b) Go routines cannot be used until you develop your own os library.

So, what's the point of writing all necessary routines in other languages (eg C, asm) and use Go as a script-like program that just chain the routines?


But don't get me wrong, I agree you may use Go to implement part of the kernel, just as well as any other language. For hobby project everyone has total freedom, pick the one that you feel comfortable and interesting. For commercial project, well, there is almost no commercial OS project so don't worry about it.

Go uses and ABI that is incompatible with C, so if anyone link Go against C code there will be some conversion involved.

Yah, you are correct. I was far too snappy on this point. I should have stuck to the point of sticking with Go and assembly.

So, what's the point of writing all necessary routines in other languages (eg C, asm) and use Go as a script-like program that just chain the routines?

You shouldn't write the necessary routines in C, C++, other. Again the point is to use the language of choice (in this case Go). One should note, even if you were writing your kernel in C, or C++ you would have to write some code in ASM... the same is true of Go. I provided a link above that says exactly how to do this in Go.