The Transterpreter Project

Concurrency, everywhere.

Compilers: Some reflection

Some time ago (but only a few posts ago), I ranted about the state of embedded systems development under Linux. If we break the rant down, it basically read like this:

How come I don't have carrier-grade compilers for every single chip under the sun for free? This is ridiculous!

The truth is, these tools have a cost. GCC is a great resource, but the number of platforms that can be realistically supported through gratis development is actually, quite likely, small. One way that it could be done is if every hardware manufacturer employed one or more GCC developers to maintain back-ends for their CPUs. Perhaps some manufacturers do just that.

However, they'd also have to maintain drivers for the programmers that connect to their chips, and make sure that you could debug the hardware from GDB on Windows, Mac, and Linux---which is a non-trivial amount of work. So, now you're maintaining a toolchain that goes from the compiler, to the linker, to the driver for the programmer... and there's probably a standard library to maintain as well.

What I'm starting to see (from being in an engineering school) is that people don't always have the mentality that they can build things themselves... when it comes to software. Because I wrote a linker for a weird little instruction set, and helped write a bytecode interpreter for that instruction set, II have a different perspective regarding the authoring of software than, say, your typical mechanical engineer. I have no real way to compare, but I suspect I sit down and think about the design and implementation of compilers or distributed systems in much the same way they think about... drivetrains and ... moving... things. Or something.

I've been wrestling with getting the Transterpreter compiled for a particular MSP430 part. You see, there are a number of parts in the MSP430 family that GCC supports very well---and we have compiled and executed occam-pi programs on those CPUs just fine. But the development board I purchased for $120 has a CPU that is... less-well supported. As in, I need to build a patched version of binutils to get things working. I spent the better part of six hours last weekend debugging what was going wrong and attempting to get things running, and finally realized that my time was worth more than the cost of a tool.

Rowley Associates produce the Crossworks line of compilers for a number of embedded processors, including the MSP430 family of devices. Lets look at their prices:


Right now, I'm too busy to chase after broken builds of binutils. Six hours of my time, valued at $25/hour, is the cost of a compiler that handles the CPU I'm trying to build for, as well as many others. And not only that, but the IDE and tools will work on Windows and Linux... and soon my Mac.

In other words, I get the IDE on Windows, Mac, and Linux for $149. My problems of getting my software to compile on the MSP430FG4619 simply go away. Does this help the next person who comes along and wants to run the Transterpreter on this chip? No. However, they'll have the same options I currently have:

  1. Get the GCC-based tools to work
  2. Buy the compiler

If I had infinite time, I would get the GCC toolchain working. But I don't. I just want the devboard to work, so I can test and demo our VM on a small platform. And because other projects I'm involved in leverage the MSP430, the compiler won't hurt there, either.

So, as soon as I get another hour or two free, I'm buying the Crossworks tools. I'm no longer a grad student with infinite time---and this is a battle I can afford to win with cash.


  • Posted: October 13, 2007
  • Author: Matthew Jadud
  • Comments: None
  • Tags: None