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:
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 http://www.imagecraft.com. 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