How SPLat works: Anatomy

SPLat controllers are made using off-the-shelf microcontroller chips. We currently use the Freescale '9S08 family of chips, with Flash memory sizes up to 128KB, and a variety of ARM chips.

You write your SPLat program using our programming software SPLat/PC. SPLat/PC must 'translate' the program before you can download it to the SPLat board. The translation process converts your program from text that you can read on your screen into a very compact form the processor chip can use. That form is not the native language of the physical processor. Instead we use a code which is a compacted form of the SPLat language (the technical term is bytecode, as used in Java and .NET). One line of your program, maybe 20-30 bytes, reduces to 1 or 2 or 3 bytes of bytecode.

Inside the processor chip there is a program that we call the 'operating Firmware'. This program is loaded into the chip by us when we manufacture the board, thus turning the general purpose processor into a SPLat processor. Part (a major part!) of this program is the SPLat Virtual Machine (VM). The VM reads the bytecode representation of your program, one instruction at a time, figures out what it means and then goes and does it.

This may seem like a very round about way of doing something. Why not simply translate your program into the chip's native language directly? The main reason is that the bytecode is very much more compact than the same functionality in native machine code. It may take 10-30 native instructions to produce the effect of one SPLat instruction. One test we performed suggest that SPLat bytecode is about 10 times more compact than a leading real-time C implementation. Remember, SPLat instructions incorporate a lot of high level functionality that is fine-tuned for controls applications.

Using bytecode gives another benefit in addition to saving memory: The SPLat VM has control over everything that happens. If it doesn't like something your program is about to do, it can prevent it from happening. A simple example is a floating point division; if you attempt to divide by zero the VM will not "explode", which is what would happen in many other environments. Your program will continue to run. The VM manages the execution of your program and eliminates a raft of possible problems.