Every so often I like to sit down and think about how to do things differently. What would a language based on tree structures look like? How could you do parallel computing in a general way with no effort? What would a CPU look like if you had no preconceptions?
That last one is a favorite of mine since I enjoy designing CPUs (yes, I need to get out more). One result of that kind of brainstorm was Oneder, my CPU that uses a single instruction.
I do tend to go down the same rat hole when I think about alternate CPU architectures, however. I start to think about how software has become event driven. Then I have the brilliant flash of insight that we could make an event-driven CPU. Then I realize that I am reinventing interrupts, again.
Interrupts are a great thing, of course, although they are notoriously difficult to get right. The Apollo Guidance Computer, for example, wound up having interrupt overruns during the first moon landing. But the idea is simple. The CPU gets some sort of stimulus, saves what it is doing, does something else to respond to the stimulus, and then keeps right on going where it left off. Modern operating systems like Windows or Linux would be hard to imagine without interrupts. Many embedded systems use interrupts for tasks ranging from dealing with time-critical input, generating periodic waveforms, or waking a processor up while it mostly sleeps.
But are interrupts necessary? I don’t mean can we make a stripped down CPU that doesn’t use interrupts. Of course you can do that. I mean, can we think of a generally applicable CPU architecture that doesn’t need interrupts to get common jobs done?
I keep trying to think about that, but I don’t have much success. However, my old friends at Parallax dreamed up a way around the interrupt problem. I’m not sure I’m totally sold on it, but I will admit it is novel and gets rid of the interrupts at the user program level.
The Parallax Propeller chip doesn’t use interrupts. What’s the alternative? The simple answer is polling. You don’t need interrupts if you just sit and wait for your external stimulus to happen. Of course, that’s not fair, right? The whole idea of interrupts is that you can do things while you are waiting for the stimulus to happen. Well, that’s why the Propeller has 8 separate CPUs.
The idea is that instead of writing an interrupt handler and making the single CPU stop what it is doing when an interrupt stimulus arrives, a Propeller programmer just dedicates a whole CPU (a cog) to waiting for that event. The cog goes to sleep, and wakes up to service the event without impacting any of the other cogs.
That has several advantages. First, it is clean and simple. It is also highly deterministic. You can even service multiple events at once. What’s the downside? Coordinating the cogs is a bit difficult. If you need to use shared resources, there is a round-robin scheme to allow each cog a turn at the common items.
The Parallax Spin language helps manage it all in a high-level language, although I’m not a fan of the Python-style space indentation, which Spin uses.
Here’s a snippet of Spin example code from the Parallax documentation:
routine1_cog := cognew(Parallel_Routine_1(6, 365, -1), @cogStack) + 1 routine2_cog := cognew(Parallel_Routine_2, @cogStack) + 1
This might look like starting two new tasks, but in fact, it is allocating two CPUs (cogs) to run some code independently.
I hear Parallax is working on a new version of the Propeller, and honestly I don’t know how popular they are in commercial designs or even hobby designs. But that’s not really my point. My point is that even though we all know that a CPU has to have interrupts, here’s an example of a highly useful one that does not have interrupts. You have to wonder what other novel architectures we could find – maybe some far better than what we have today – if only we would think outside of the chip. Well. Outside of the box.
Are you using the Propeller? Or some other novel architecture? What would persuade you to adopt a radical new architecture? Leave a comment and share your thoughts.