gccgo ?
Heater.
Posts: 21,230
Hate to suggest work for the GCC team and this may have been suggested before but recent versions of GCC support the Go language.
http://golang.org/doc/install/gccgo
Any chance of propgcc getting Go support some time?
http://golang.org/doc/install/gccgo
Any chance of propgcc getting Go support some time?
Comments
...of course having to have the opening brace for a code block at the end of a line instead of its own line would drive some folks as mad as a hatter!! :0)
Getting the language to compile may be as simple a matter as unpacking the go sources for gcc 4.6.1 into the propgcc tree and then rebuilding. That's basically what I did for Fortran. I have the feeling that I may have had to change a config file to enable fortran as well, but I can't find my notes on that now. Anyway, getting the compiler to build was pretty much trivial; no source code changes were required.
The run time support is another matter entirely, as Rick said. The Fortran libraries are too big to fit in hub memory even with CMM, and those should be a simpler runtime than Go. The GNU people seem to assume that any library less than 1MB in size is small enough, which is fair for desktop machines but not quite appropriate for us :-(.
Eric
Hi,
I'm, among other languages, a Go programmer and a minor contributor to the Go project. I would like to try to write/help to write a propeller-grade C RTL for Go in an attempt to enable Go on Propeller (or possibly some usable subset of Go). But - my free time is limited and my knowledge of GCC internals is next to nothing. Nonetheless, if there's any interest in the propGCC development team about having Go support, please let me know, TIA.
-j
@jnml,
Sounds interesting. Time is precious of course.
I'm not a Go programmer, but would love to try it at some point (more than hello). Simple examples look very intuitive.
I would love to see what kind of features would be considered a usable subset.
Thanks.
--Steve
At the risk of being silly, I would try to define a "usable" (feature) subset of (embeded) Go roughly as:
Go 1.0.3 with following features removed (in no particular order) for an initial porting attempt:
- Compiler/CGO support.
- RTL/Reflection support: Essential to e.g. package "fmt", but cheating w/ C printf for the same reasons (a lot of precise code bytes) is a precedent.
- RTL/Garbage collection (but only in the first proof of concept).
- Package "runtime": Keep only GC(), Goshed(), Error, circa.
- Select statement[1] possibly busy waiting (probably removes a lot of RTL complexity - altough an implementation detail only).
- Running other goroutines during init(). Probably possible to add sometime later.
As can be seen, the language (semantics) is not affected, only the standard and run time libraries. And the former mostly indirectly by the later. Additionally, but naturally - any complex/big enough package disqualifies itself from the LMM/CMM model (COG is not an option at all I guess).IMO using the nice standard library which Go has is not actually the point of porting it to the Propeller. It is the nice parallelism/concurrent support built into the language which makes Go potentially well suited for it.
My 2c.
-j
[1]: http://golang.org/ref/spec#Select_statements
I still like the language concept. Being able to write a program on line and run it in a browser is neat.
Does the compiler run as a server process? I guess Google has lots of servers to share the load.
I do remember Chip talking about wanting to find a more parallel suitable language for Propeller. Maybe Go is a candidate?
Thanks for your list. It's very interesting.
--Steve