The Go language for embedded systems

Posted by Cliff Brake on 2010-01-06 | 4 Comments to Read

As one of the things I do is evaluate new technologies for embedded systems, the Go language from Google is an interesting development.  I have been looking for a better “system” language for some time.  What I mean by a better system language is one that is nearly as efficient as C, does not require a large runtime, has a fast start-up time, and yet supports modern language features.  It is interesting that the constraints for very high performance server applications are often similar to those found in embedded systems in that applications must make very efficient use of memory and CPU cycles.  This is why C++ is still used a lot by Google and is also popular in embedded systems, but is not as common in applications where CPU power is plentiful compared to the resources to implement the application such as business applications.  One area of divergence is the focus on multi-core for high end server applications, but in the next few years, multi-core CPU’s such as the Atom and ARM Cortex-A9 will likely be common in low power embedded systems.

There are other options.  Vala is very nice to use, is efficient, offers advanced language features, and extensive language bindings.  Vala is being used to implement some of the http://freesmartphone.org software stack.  C/C++ are the old standby languages, but are rather tedious to program in compared to some of the newer languages in that source and header files are separate, and memory management is manual.

My interest in Go at this time is for ARM systems, so I ran a few experiments.  From what I can tell, there does exist an ARM Go compiler that is able to produce ARM code, but it currently lacks support for EABI soft floating point.  The lack of floating point support is pretty much a show stopper for now, but it is at least a start.  The following is an example:

export GOARCH=arm
cd $GOROOT/src/
./make-arm.bash

cd
(create the following source file: hello.go)

==================
package main
import "fmt"

func main() {
        fmt.Printf("Hello, world\n");
}
=================

5g hello.go   (5g is the ARM compiler)
5l hello.5
scp 5.out root@n900:  (copy to ARM system)
ssh root@n900
?:~# ./5.out
Hello, world

(modify with floating point code)

==================
package main
import "fmt"

func main() {
        var f = 1.5;
        fmt.Printf("Hello, world\n");
        fmt.Printf("float f = %f\n", f);
}

=================

(now run on ARM system)
?:~# ./5.out
Segmentation fault

As, you can see, floating point does not work as expected.  I’m not sure yet if gogcc can be configured to compile ARM binaries.  The other area where Go appears to need a lot of work is bindings to various libraries.  Though it does not appear to be ready for embedded ARM systems at this time, Go will be an interesting language to watch over the next few years.

  • Ken Gilmer said,

    Hi Cliff, great post. I’ve also been interested in alternatives to C as a system language, and what ramifications they would eventually have in what can be (cheaply) done in FOSS OSs. I look forward to seeing progress of Go on ARM.

  • Al said,

    Hi Cliff

    You should also join this thread down at the Golang group

    Embedded how low can it go :

    http://groups.google.com/group/golang-nuts/browse_thread/thread/1ff3a74df406288b/d823d4874507066d#d823d4874507066d

    I believe Goog have done a lot with ARM for Go, always worth just asking at the group

    regards
    Al

  • Fernando Palha said,

    Hi Cliff.

    I’ve also been interested in alternatives to C/C++ to ARM Linux embedded development.

    The new Go release, release.2010-04-27
    changes:
    * arm: add android runner script,
    support for printing floats.

    http://groups.google.com/group/golang-nuts/browse_thread/thread/3faf157bd09526be/f1e0b14ab6407497?lnk=gst&q=embedded+linux+ARM#f1e0b14ab6407497

    Do you can test it?

    Regards.

    Fernando Palha

  • Steve Merrick said,

    I write for embedded environments which will probably never use multi-core monster CPUs such as those you mention. We use processors like the LPC1100 or MSP430, and we’re still grateful to C for rescuing us from the primordial assembler swamp. 🙂 Will there ever be a successor to C for us, do you think? Could Go be it? [How about Vala?]