Instruction set for a 4-bit HRRG Steampunk Computer

Sad to relate, I haven’t gotten around to completing Part 4 of my Heath Robinson Rube Goldberg (HRRG) Steampunk Computer mini-series this week (Click Here to see Part 3), but this is because I’ve been pondering its instruction set…

Before we plunge into the fray with gusto and abandon, I should note that an executive decision has been made that the HRRG Steampunk computer will be a 4-bit machine; specifically, it will have a 4-bit (1-nybble) data bus and a 12-bit (3-nybble) address bus. [Remember that “Two nybbles (or ‘nibbles’) make a byte,” which goes to show that engineers do have a sense of humor … it’s just not very sophisticated.]

Why a 4-bit machine? Actually, there are two main reasons. The first is that I always wanted to construct, and play with, a 4-bit computer. The second is that I want the final machine to be educational and understandable to a wide range of folks, including younger guys and gals like high school students. A 4-bit machine is, in many ways, easier to wrap one’s brain around than a larger machine. Of course such a machine also poses some limitations, but that’s all part of the game.

Now, before we proceed, I think I should bring you up to speed with at least part of the “Master Plan” (for future reference we will call this “Plan A” so that no one gets confused). My co-conspirator on this project is my friend Joe Farr in England. Joe and I have been involved in a number of crazy schemes over the years. My specialty is coming up with wild and wacky ideas; Joe is a hardware and software guru who can build or code just about anything; so combined we make a crack team that’s ideally suited for something as weird and wonderful as the HRRG.

But, as usual, we digress… consider the image shown below. This is a screenshot of a software emulator Joe created to represent a physical machine he’s in the process of constructing (Click Here to see a larger, more detailed version of this image). Joe created this emulator in order to experiment with different architectures and instruction formats and suchlike.


This is, of course, a significantly more complex machine than the HRRG, but I think it will give you a better understanding of where we plan on taking all of this. The starting point will be to create a software emulator for our HRRG Steampunk Computer (hereon after to be known as “The Beast”). As soon as this emulator is up and running, we will make it (along with associated tools like an assembler and suchlike) freely available for anyone who wants to play with it.

As part of this, we will also define an external interface that will allow portions of the virtual machine to be swapped out with their physical counterparts in the real world. The idea is that anyone, from individuals to groups of high school students, will be able to build their own physical cabinets containing things like the system clock or a block of ROM or RAM. For example, you might decide to construct a cabinet containing as little as say one 4-bit word of memory. This could be implemented in any technology of your choosing, such as relays, vacuum tubes, juggling hamsters… You could then connect this cabinet to your computer and run it in conjunction with our virtual machine.

Personally I am very excited by all of this, but first we have to make some basic decisions. As I previously mentioned, Joe and I have agreed that The Beast will have a 4-bit data bus and a 12-bit address bus. So, our next step is to decide on the underlying architecture of the machine, and part of this is to specify its instruction set and addressing modes.

One important consideration is to ensure that the machine is defined in such a way as to make it as easy and intuitive to implement as possible. It would be more than possible to create something in the virtual emulation world that would be a pain in the rear end to implement in the real world, and we certainly don’t want that, do we?

So, we are currently bouncing ideas back and forth across the Internet like ping pong balls. Do we need a stack or can we get by without one? If we do decide to support a stack, then which (how many) stack-based instructions will we offer? Will we support a simple interrupt structure or not? Should we support the concept of an index register? If we use only a single 4-bit nybble to represent an instruction, this gives us only 16 possible instructions, so which instructions do we have to support and which can we live without?

As a simple example, consider the logical instructions AND, OR, XOR, and NOT. That’s four instructions, which is a quarter of the total number we can support. Do we need them all? Well, we could probably live without the NOT (which simply inverts all of the bits) because we can achieve the same thing by XOR-ing with all ones; for example, %0110 XOR %1111 = %1001 (where the ‘%’ character is used to indicate a binary value).

In fact, we can go one step further, because we can actually live without an XOR, whose operation can be replicated using AND and OR instructions. To be perfectly honest this was a new one on me – Joe told me about it yesterday. Consider %0101 XOR %0110 = %0011. So how could we replicate this using AND and OR instructions? Well, if we AND our original values we get %0101 AND %0110 = %0100. And if we OR our original values we get %0101 OR %0110 = %0111. Finally, if we subtract the result from our AND from the result from our OR, we get %0111 – %0100 = %0011, which is the same as the result from our original XOR… clever, huh?

In fact there are so many tradeoffs like this. Here’s another one – if you have only two instructions to devote to shift/rotate type instructions, is it better to have shift-left and shift-right, and to then use the results to emulate rotate instructions if required, or vice versa?

Of course we could overcome our self-imposed 16-instruction limitation by supporting multi-nybble instructions. Two nybbles (8 bits) would allow us to support 256 instructions; three nybbles (12-bits) would allow us to support 2,048 instructions, and so forth. But where’s the fun in that? Also, we want to abide by the KISS principle (“Keep It Simple, Stupid”), so we’ve stuck a stake in the ground and said: “One nybble for the instruction, plus extra nybbles for operands like constant values and addresses (always assuming that we decide to support constant values, of course).”

Joe and I are just at the stage of bouncing ideas back and forth via email at the time of this writing. Our original ideas were so different to each other’s that it really opened my eyes as to the various possibilities (I’m not happy that his ideas are better than mine, so I’m in the process of “tweaking” them while he’s not looking [grin]).

But the bottom line is that this would be a great time for you to chime in with your thoughts on this matter (you can add a comment to this blog, or you can email me directly at max@CliveMaxfield.com). At this early stage of the game, anything and everything can contribute to “the mix.”

When we’ve gathered all of the ideas and made some decisions, I will pen an article describing the way in which we swung back and forth on this and how we finally arrived at … well, whatever solution we finally arrive at (grin). Until then, have a good one!