The Transterpreter is an small virtual machine for executing occam programs on a diverse set of computing platforms. Currently, the VM can run on Mac OS X, Windows, Linux, Solaris, FreeBSD... the list of desktop platforms goes on-and-on. We're known to run on the Nokia Series 60 platform, as well as the Sharp Zaurus (ARM), and the Texas Instruments MSP430 series, a power-savvy, 16-bit chip often found in a variety of embedded systems.
However, our project is more than just the virtual machine. Our goal is to develop a viable platform for researching languages for concurrent and parallel control in embeded, desktop, and cluster applications; no other concurrent programming language currently spans that range. We see a number of tools as being important in this overall goal:
Our current VM was designed to be small, portable, and simple to understand. It's a great place for students to start exploring virtual machines and hardware. For example, we're really hoping to end up in the LEGO Mindstorms NXT developer program, in which case we'll be porting the Transterpreter to the NXT to run native. That should be very cool. (There's a half-dozen other places we'd like to be as well... the Palm, Windows CE, Hawaii... to name just a few.)
We're developing a new compiler, which we generally refer to as 42. This is largely a learning exercise for the team; we're ultimately interested in novel, heterogeneous compilation targets, but are starting simple: occam2.1, targeting the Transterpreter. This compiler will be reliable, well documented, well tested, maintainable, open (in its design and for future linguistic exploration), and hopefully extensible. It is very important to us that this work takes place as a team, and that we learn about the language and process of writing compilers through our efforts.
Currently, we make the Transterpreter generally available as a plug-in to JEdit, an open-source editor written in Java. This is great, but occam is a highly visual language---process networks should, we think, be diagrams. While we have not yet started a visual process editor for occam, it would be an invaluable contribution to our overall project goals.
We are about to deploy our first major application, which is a complete Linux build for VMWare that includes both the Player/Stage simulator as well as libraries to connect occam programs to both virtual and real Pioneer3 robots.
However, the Transterpreter will be playing an increasing role in wireless sensor network research here at Kent, and the opportunity to explore this exciting and emerging field of research is really quite cool. Likewise, we have some good ideas for using occam for controlling parallel computing cluters, as well as more widely distributed frameworks like that used in SETI@home. Unfortunately, it takes time to develop and maintain the VM and compiler as well as develop applications (which, really, is the fun bit). So if you've got a mind for concurrency, or think you'd like to develop one, there's lots of things you can do to contribute without working on the core.
Actually, everyone needs to do more of this. However, it is probably possible for the interested student (or anyone, really) to join us as a technical writer. As a third-year project, I suspect one could do solo or small-team work writing documentation and examples. This is not, however, an easy route. It's actually quite challenging---you have to understand what you're writing about, and be able to communicate those things simply and clearly, often with examples in code. While it is often considered unglamorous, I often consider a project no better than its documentation. In this regard, the Transterpreter is currently awful, and projects like the DrScheme/MzScheme project is amazing.
You don't have to be at Kent to join in the fun, but it certainly is easier at the moment. Drop us a note if you want to learn more.