Thread this Mr. Interrupt!

Ahh yes ... Threading in software development has always been a powerful but expensive technique. Not Cash Money expensive ... Brain Money expensive. You have to make sure your not tromping on other memory and interrupting your way around life (what! Stop my current process so you can do something?! Ha!). All the while trying to keep clean and precise code. What if it didn't have to be that way? What if your Video driver didn't have to interact with your running thread via interrupts. What if you could just say "Video Driver ... please give me a display" and it starts it's self and runs on it's own core with it's own memory with out the worry of trashing other processes memory ... AND NO INTERRUPTS!

Enough interrupts already.

This is a Huge topic here recently in software development. We are getting more and more multi-core processors with more and more cores. Mores Law stats that will only increase exponentially ... to the point that no "man in the middle" controller could keep up with the requests. Also just imagine the amount of interrupt hardware would need to be implemented for each core.

For A Change, I Think It's Time For A Change!


The Propeller microprocessor has exactly what I have been looking for in a processor. This is an 8 core, 32 bit, 80MHz, 160 MIPS, 40 I/O pins power house. This processor doesn't use interrupts in any fashion. At first this was such an odd way of developing but now I wish I could develop on nothing else.

This is a basic run down of how to develop with this chip.

First you write an "Object" (Parallax's way of maintaining some OO functionality) that does a task such as generating video that prints text to a TV. This Object would have a few public functions that you can pass data to and from the object, such as what text to print. Then you develop a second object ( lets call it "Controller") that will "instantiate" your TV Object and pass text to it.

When the Propeller starts up it loads your Controller Object into the first available processor. Your Controller Object then call a "Start" function in your TV Object witch starts a second processor with the code for your TV driver. Now both Objects are running at the exact same time on the exact same clock cycles but completely independent of each other.

Your Controller Object could also load a Keyboard Object that does nothing but watch for input from a keyboard. During the long pauses between key inputs your Controller object doesn't have to wait for an Interrupt to return from the Keyboard Object to continue to pump data into the TV Object. So now you have 3 processes running on completely different processors all at the exact same clock cycles.

Do you see the power here? I don't have to write any special techniques to handle waiting on a process to finish so I can updated my display.

Now there is still shared memory that needs a "Man In the Middle". On the Propeller they call this the Hub. If you look in the Graphics above you'll see a kind of wheel with an end that moves from each processor to the next. This is a slower process but is easy to take into account while developing a tool.

Now for the REALY kewl stuff. HYDRA Game Development Kit ::: I wont go into it ... but check it out!!!