Parallax Propeller and the Propeller C Compiler

I worked at compiler teams for a few companies before founding ImageCraft: large ones like DEC (RIP) and HP, but also smaller ones like Whitesmiths and Intermetrics. The joke is that when a company promotes their latest chips as “co-designed with C compiler experts,” it means that they’d sent us poor compiler writers an email after tape-out. In reality, C is a fairly easy language to support – the experience of the early C designers when they first wrote PDP-11 Unix in C, and then ported it to a different architecture (the Honeywell 635, a mainframe) helped hone C to be what it is: a lean programming language that can feel as comfortable in writing firmware, system software, all the way up to complex application code.

Some (new) architectures still don’t quite get it though. At least the 8051 has the excuse of being a dinosaur from another age, but architectures with data and (worse) code paging are definitely a step backward for seamless support for C. And lets not talk about memory that is only word addressable or highly asymmetrical addressing modes. Great joy.

Then there is the Parallax Propeller. An absolutely brilliant architecture in its simplicity: 8 32-bit processors (Cogs) with shared resources which are controlled by a central hub. With 8 Cogs, it eliminates one of the biggest source of problems in embedded systems: asynchronous events resulting in interrupts. Need to monitor a hardware pin? Throw a Cog at it. Need fast serial IO while you are processing data? Throw a Cog at it. No more worrying about interrupts coming in at the wrong time or nested interrupts. Life is good… except for the memory hierarchy: each Cog has its own 512 longs (32-bit) memory, which can be used as both instructions or data storage depending on how the program uses the memory. Self-modifying code is used extensively, including for the call and return instructions. The shared memory is a whopping 32K bytes, but a Cog can only access it as data, relatively slowly at that.

So I was staring at this strange beast: what use is this for C programmers if programs are limited to 512 longs (and less since we do need some data storage)? It doesn’t even have a stack, for crying out loud. Parallax’s solution to the problem is that for their Spin toolset, a Spin program is compiled into bytecode tokens, which are then interpreted by an interpreter which fits in a Cog. A Spin program then is limited by the size of the Hub memory, but at the cost of as much as 40x slower than native code.

For the ImageCraft C, I felt that bytecodes are too slow and negate much of the power of the Propeller. A better solution is needed. Fortunately, Parallax has a very active forum with many supportive and importantly, smart users. One of posters, Bill Henning, made a startling simple observation:

nxt     rdlong   instr,pc
add      pc,#4
instr   nop      ‘ placeholder!
jmp      nxt
(Basically, read a native instruction addressed by a virtual PC from the Hub memory, increment the virtual PC, execute the fetched instruction, then repeat)

By running a small loop like above, a program can be as large as Hub memory and execute in about 20% of native code speed, exactly what is needed to make a C compiler product viable for the device. So this Large Memory Model LMM (or rather an optimized and flushed out derivative of it) is what we use in our Propeller C. A number of other LMM kernel routines are needed of course. And with our latest release, we added support for FCACHE – a method to run small loops at near native speed. So Propeller C balances quite well between the two official Parallax tool offerings: compare to the native ASM programs, it’s about 25% as fast but have full access to the Hub RAM (and access to even higher capacity memory devices if one were to modify the LMM kernel). Comparing to Spin, the code is about 3 times larger but about 4 to 5 times faster. Not a bad tradeoff.

You can learn much more about our Propeller C at our website You can even download a fully functional 45 day demo. Propeller C supports the native multiprocessing features of the Propeller so you don’t lose anything by using it. Propeller is an exciting new product from a company that does things differently but often right. It does not yet have some features than some embedded users may take for granted such as code protection, but it is an exciting technology that you should check out, and now with ImageCraft Propeller C, there is one less reasons not to test drive it.

Finally, to tie in with the previous post on REXIS, with its multiple Cogs, Propeller is an ideal environment for REXIS.MkII. There is even a *possibility* of stacking multiple Propeller together, for even greater amount of memory and processing units. Exciting time indeed.

// richard

REXIS (V2): The Subsumption Architecture OS

Subsumption Architecture was defined by MIT’s Rodney Brooks as a new method of building intelligent systems based on reactive behavior based control. While 20+ years later, the promise of the subsumption architecture has not produced an intelligent robot yet (although I suppose we don’t *really* know the full capability of the PackBots used by the military :-) ), the subsumption architecture remains an enticing theory for building control systems. With the ever increasing use of embedded micrcontrollers and sensors, the subsumption architecture becomes an appealing choice for such system due to the following properties:

  • The architecture is inherently multiple process and processor friendly. This is useful as the number of control units increase.
  • In real world, messages are inherently unreliable and missed deliveries are possible (e.g. imagine a noisy wi-fi network). The subsumption architecture design are divided into levels of competence, providing a high level of robustness in unreliable message delivery environment.

Our first commercial product was REXIS (Real time Executive for Intelligent Systems), a C library implementation of the subsumption architecture. It is a multitasking RTOS with support for subsumption calls. I am now designing V2 of this system.

To make the system as user friendly as possible and to obtain the best performance, the system consists of:

  • a RTOS (real time OS) with subsumption API, plus traditional API such as semaphores.
  • a language preprocessor.

The source file is a C source file decorated with the REXIS language elements, which are prefixed by the @ sign. Some are commands and some are used in place of C expressions. The full power of C is available since the REXIS elements are just small part of the source program.


Guitar Hero and the ImageCraft AVR C Compiler

One of the hottest console games currently is Guitar Hero. It’s hugely entertaining and you get to enjoy some good music. On the downside, it doesn’t have anything to do with playing real guitar per se as the primary task is to push the right buttons as shown on the screen. To address these shortcomings, Zivix has developed a guitar with an Atmel ATMega168. The designer, Dan Sullivan,  says

We have been using the Imagecraft C compiler for the Atmel AVR for many years, and it has been a great workhorse for code development. We use an Atmel MEGA168, so having efficient code is important to squeeze in the many functions into the small memory space available.

I am very glad that we can be a part of Dan’s ingenious solution. In Zivix’s guitar, since the game requires “chords” on one string, Zivix has patent-pending sensors integrated into the fretboard. This makes the guitar act as a bridge between game playing and learning a real musical instrument. Instead of pressing colored buttons on a simulated plastic guitar, the user places their fingers on the frets, and instead of using a plastic paddle switch, a string must be picked using a conventional pick or finger. In this way a game player can learn to fret and pick strings on a real guitar, and this provides a first step to learning to play it. The guitar can then be disconnected from the game, plugged into a normal guitar amplifier, and used to learn the real songs.

For more information, please visit their web site,

In the Beginning…

Our first compiler product was a low cost ($39!!!) C compiler for the HC11. The ’11 was great for its time: the documentation is a standard that most CURRENT microcontroller documents could take lessons from; the chip was easy to use, even in the era of burning your own EEPROM and erasing them using UV light, and the HC11 E2 was a charmer since it has its own builtin 2K of EEPROM, back in the late 80s!

But I digress, ImageCraft had an earlier beginning. Back in the days when I was in the graduate school, I got very interested in MIT’s Rodney Brook’s subsumption architecture (*) and I did my Master thesis on a subsumption based C kernel (demonstrated with a RC-converted robot named Ripley). Then I decided to see if I can commercialize the kernel. As with all product launches, the naming took longer than the development time (ok, I exaggerated), and the kernel ended up being called REXIS, short for REal time eXecutive for Intelligent Systems. I forgot exactly how it happened, but someone at the Canada Forestry paid us a lump sum of $1500 to port REXIS to the 68000. They were embarking on a decade long project to build autonomous forest tending robots and REXIS fitted the bill, and thus ImageCraft was born… They actually sent us a VHS tape of the robot in action. It’s a huge 4 legged walking robot, able to negotiate rough terrain. I wonder if the clip is on youtube :-)

To close the story, it didn’t make much sense to sell a HC11 C kernel suitable for robotic uses when most roboticists/students could not afford a $1500 compiler, so I decided to write and sell a low cost HC11 compiler…

REXIS morphed into the simpler uExec, which we published in a Circuit Cellar article and is available on our website for several targets. One person added messaging API and another person ported it to the M16C. Unfortunately, I have not gotten these enhancements. In any case, I still have a soft spot for REXIS and I may resurrect it in a more modern form one of these days.

(*) funny enough, Brook’s eventual company started by one of his students, iRobot, is one of our customers…