The Transterpreter project was born three years ago around this time; it started life as a Scheme implementation of a Transputer bytecode interpreter, and has grown quite a bit since then. Given that we’re starting into 2007, it seemed like a good time to give an update about what is going on in the group. In no particular order:

• Jon Simpson (third-year undergraduate at Kent) has been working on revitalizing the LEGO Mindstorms RCX port of the Transterpreter. The old version was built on top of BrickOS; we were, effectively, running two operating systems on the LEGO, one on top of the other! Jon is at the point where he has the Transterpreter running natively on the LEGO Mindstorms RCX, can handle button input (including a nifty, non-blocking debouncer), and is continuing to slowly build up to more useful end-user interface code. By March he expects to have a complete and usable (native) port of the Transterpreter on the RCX. (/branches/new-lego)

  Looking forward, Jon (and the rest of us) are excited about getting the NXT port of the Transterpreter rolling. We have already had some interest expressed from others about taking part in this effort; we’ll be generating some mail on that shortly.

• Damian ended the year cleaning up his Cell port of the Transterpreter (/branches/cell), with particular attention being paid to developing a native, big-endian port of the Transterpreter (/branches/big-endian). Currently, we pay a penalty on all big-endian hardware, and Damian (and other’s) efforts in this regard will give us full, native performance on big-endian platforms; this effects the PowerPC (Mac, Cell) and Mindstorms RCX, among others. Looking forward, he is coming back to 42 (our experimental compiler), and wants to work out the critical points in generating little/big endian code as well as “fat binaries”.

• Adam Sampson picked up a few Arduino boards (http://www.arduino.cc/), which are driven by an Atmel ATmega8. This little chip has roughly 7KB of free flash and 1KB of RAM; it represents the smallest device the Transterpreter has been targeted at yet (/branches/arduino). While Adam’s intent was to develop an Arduino port of the Transterpreter, he says that “in the process I’ve done a load of cleanups which are probably more useful than the work I was intending to do.”

  The “cleanups” that Adam has made in the Arduino branch are (in his words):

  1. wrapper (currently untested) for the ATmega8

  2. instruction dispatching via switch, so all the instructions end up inlined, which cuts the code size considerably (and should make it a bit faster)

  3. some fixes to comments

  4. consistent ANSI C prototypes throughout

  5. add multiple-inclusion guards to all the headers

  6. make the word size code use inttypes.h and be configurable at compile
     time

  These are all nice cleanups that will ultimately be merged back into the trunk, and therefore benefit all of the Transterpreter ports.

  Adam’s explorations also involved cleaning up the “memory array” code (/branches/mem-array). When originally developing the TVM, we had a “virtual memory”, which made detecting a variety of faults easier; this was the original memory interface for the Transterpreter, but was dropped shortly after porting to C. Adam has cleaned this up as well, and (in his words, again):

  1. make the array memory backend actually work (mostly with the aim of being able to use a non-native word size, although I haven’t yet tested that)

  2. do bounds checking in mem_array so that the TVM stops (rather than
     segfaults) in the event of a bad memory access

  3. fix a number of bugs related to string handling and memory allocation which were revealed by Valgrind; we need to do a Valgrind run with some proper code (using dynamic memory) at some point to try and shake out more

  4. completely rework the code in stiw that builds the memory map, since it had a number of bugs and didn’t work with mem_array before

  5. fix a few bugs in interpreter revealed by the work above

  These are all excellent, and again will find their way back into the trunk. Indeed, as part of his explorations, Adam generated a number of tickets that I added to Trac (http://trac.transterpreter.org/), and we can begin addressing in the interpreter, which is good.

• Matt Jadud (that’s me) has been focusing on the MSP430 port, living in the Tmote Sky branch (/trunk/wrappers/tmotesky). As a side effect of this work (along with Jon Simpson), we developed ‘tinyswig’ (/trunk/scripts/tinyswig.scm), a mini, SWIG-like script that lets us quickly and easily write C extensions to the VM, callable from occam-pi. After this, we worked out the details of interacting with hardware directly from occam-pi, which (in some cases) completely eliminates the need to call out to C from occam. For example, in ‘/trunk/wrappers/tmotesky/Native‘, you can find our initial explorations in this area, where we are bringing up the virtual machine with no connections to the hardware, and then configuring the MSP430 directly from occam-pi. We expect this to make implementing functionality for new embedded platforms much easier for the developer in some cases.

  Although it is unexciting infrastructure, I also began work on migration from Autotools to Scons (/branches/scons). Currently, it is possible to build the Transterpreter for Linux/Intel, MacOSX/Intel, and the MSP430 in this branch using Scons. The build scripts are, I believe, clearer, easier to extend, and will (I believe) give us a better cross-platform build experience (eg. Windows). Currently, we have to maintain a completely separate build system for Windows, which is untenable in the long run; with Scons, we have a chance of bringing things together nicely across all major development platforms. So, while unexciting, I consider this a rather important revision of tools and infrastructure. (Of course, I’m working on it, so you might expect I’d say that.)

  Along with the under-the-radar updates to the build system, I’ve nearly finished refactoring the linker; what had grown to 5000+ lines of Scheme has been reduced to roughly 1500. While the new slinker is not done yet, it is much simpler and much more modular. The new slinker was informed greatly by our explorations with 42—the underlying data structures are far more intelligent than they used to be, and allow us to do complex things very simply. It is, in a nutshell, a joy to work with (as source code), which I can no longer say about the original slinker.

  Looking forward, I’ll be working more with two new hardware development boards for the MSP430, exploring radio communications, analog-to-digital conversion, storage of data to external devices (SD, etc.), and most importantly, the integration of interrupts with the Transterpreter scheduler. The development boards are important, as they allow me to do in-system debugging via JTAG, which will be essential for the implementation of interrupt handling. This will, like many other things we do, impact all Transterpreter ports.

• Christian Jacobsen has recently been sighted trying to set up a “build bot” for the Transterpreter project; this will automatically check out our code, build it, and run the test suite on a regular basis. However, he should not be doing this, but should be submitting the final version of his thesis. We expect that to go out the door ANY DAY NOW. I read it on my flight over to the USA, and believe-you-me, it was very, very exciting. Very.

If this sounds like we’re busy, it’s because we are. We’ve got a few other things up in the air related to our ongoing efforts, and will drop word of those as they see the light of day. If you have any questions about the project, or want to get involved, please feel free to drop me a note (matt at this domain).