Re: Go support on Epiphany
Posted: Sat Feb 02, 2013 5:52 amOkay. So having read the spec, ill catch everyone up to date with go.
Regarding the runtime, gc statically compiles the go runtime and any imported dependencies directly into the executable binary. There is no shared libraries and runtime linking or anything like that. Some may object to this due to bloated sizes of executables, however this is done in an optimal way where an entire lib isnt being compiled in. A "special" header is created via all the imported dependencies a go program actually uses. A quick example of this means that, for your package foo to reference an exported variable in bar, which itself is a imported type from package baz. Package foo doesnt need to include the baz package to know what that type is because all that information was compiled into package bar's library (bar.a).
A "hello world" go executable comes out to be about 1 mb in size. (http://play.golang.org/). Which is substantial. You wont be able to load an entire go program into a single e-core and read just from it's local memory like you would be able to using musl-c or uClibc. Here is a go implementation of plan9's version of the cat program with the source and the produced asm pre linkage. https://gist.github.com/4696208 for anybody curious.
In my opinion, running a go executable on a core by core basis is too much overhead and cycles wasted. Instead what im envisioning is that the arm cpu would handle the main goroutine, and then any subsequent goroutines called from main() can be dispatched to an available core and then popped off to be replaced by any other goroutines being handled by the runtime scheduler.
I think its very feasible to implement go for epiphany. Ill post updates here with any news.
Regarding the runtime, gc statically compiles the go runtime and any imported dependencies directly into the executable binary. There is no shared libraries and runtime linking or anything like that. Some may object to this due to bloated sizes of executables, however this is done in an optimal way where an entire lib isnt being compiled in. A "special" header is created via all the imported dependencies a go program actually uses. A quick example of this means that, for your package foo to reference an exported variable in bar, which itself is a imported type from package baz. Package foo doesnt need to include the baz package to know what that type is because all that information was compiled into package bar's library (bar.a).
A "hello world" go executable comes out to be about 1 mb in size. (http://play.golang.org/). Which is substantial. You wont be able to load an entire go program into a single e-core and read just from it's local memory like you would be able to using musl-c or uClibc. Here is a go implementation of plan9's version of the cat program with the source and the produced asm pre linkage. https://gist.github.com/4696208 for anybody curious.
In my opinion, running a go executable on a core by core basis is too much overhead and cycles wasted. Instead what im envisioning is that the arm cpu would handle the main goroutine, and then any subsequent goroutines called from main() can be dispatched to an available core and then popped off to be replaced by any other goroutines being handled by the runtime scheduler.
I think its very feasible to implement go for epiphany. Ill post updates here with any news.