In the last tutorial, we saw how memory-mapped IO lets us replace INPUT/OUTPUT instructions with regular memory access. For fun, let’s extend this idea to get rid of all instructions.
redundancy
Compare these two devices:
- The addressable storage, which contains memory devices (and possibly I/O) at different addresses
- The instruction processor, which contains instruction-executing devices at different addresses
If you squint a bit, aren’t these the same thing?
They’re both a collection of devices at addresses. We send an address to the “manager” of the collection, and it triggers the corresponding device — storing data in memory, or executing an instruction.
The natural next step is to fold them into a single unit.
instruction devices as memory
Suppose we plugged in our ADD device at memory address #20. Then, whenever we execute STORE #20, we’d actually be triggering ADD.
ADD currently expects us to supply an argument — the address of the value to be added to the accumulator. So we’d need to modify how the device works. For example, we could create a second register, and make ADD just add those two registers together.
What about the output? We just need to make sure that ADD puts its result into the accumulator.
all instructions?
Following the same approach, let’s move all our instructions — SUB, INC, etc — into memory.
We’re left with STORE and READ. But we can put READ in there too: whenever we want to read from an address, we can just call STORE #30 (if READ is at #30) and that will trigger the read operation.
So now we have just one instruction left: STORE. Our programs will now look like this:
STORE 44STORE 39STORE 11...
Do we need to keep writing STORE? If every instruction is the same, we can just view our programs as a list of memory addresses to hit:
443911...
We’ve turned our machine into an OISC — a One Instruction Set Computer. Instead of our programs selecting from an array of possible operations, each step performs the same operation each time: STORE.
There are many types of OISC, differentiated by exactly what that instruction is.
… so what is our instruction, exactly?
We’re not really “storing” things any more — this instruction does everything. We’ve shifted the complexity into the devices that it triggers. Therefore, we might think of this instruction as TRIGGER. When we say TRIGGER #30, we mean “trigger the READ device”; when we say TRIGGER #41, we mean “write to the memory device at #41”.
This specific type of OISC is called Transport-Triggered Architecture (TTA).
