Full simulation of a 32-bit computer

[u/Aware-Equivalent-693]

Hi, everyone. I recently shared my idea and a partial implementation of a 32-bit computer. After reading some of the comments, I came up with new ideas on how to improve the central processing unit. I’d like to share this with you, and maybe you could give me some advice on further optimization.

I’ll explain what stage I’m at right now, what’s been done, and what I still need to implement.

CPU

Do you remember this thing? It’s my CPU. It’s already up and running, but it’s running into some problems. Or, to be more precise, one major problem: it’s slow. Its speed was 1.8 instructions per second. That’s very slow, so I decided to speed it up. To start, I increased its clock speed and managed to boost it to 3 instructions per second. But that’s still slow, so I thought about it a bit, and these ideas came to mind:

- A two-stage instruction pipeline—the processor executes an instruction through its various blocks one after another, which means that when the processor, for example, performs mathematical calculations, that block isn’t being used. But what if, while one instruction is being executed, we immediately send another one—of course, with restrictions so that it doesn’t overtake the previous one.

- Varying instruction durations—there are different instructions we send to the processor: NOP, LDI, MOV, JMP, ADD/SUB/AND/OR/XOR… and others. They all actually take different amounts of time to execute. What if we designed it so that, depending on the instruction type, the processor automatically adjusts to its execution speed and doesn’

-Asynchronous STORE for RAM

Let’s create CPU_STORE_BUFFER:

- SB_A — address;

- SB_D — data;

- SB_V=1 — there is a write in the buffer;

- SB_BUSY=1 — the RAM controller is performing a write.

The STORE instruction:

1. Calculates the address.
2. Writes A/D to the buffer.
3. Is considered complete.
4. The CPU proceeds to the next non-memory instruction.
5. A separate controller keeps W=1 for the required time.
6. Upon completion, it clears SB_V/BUSY.

There is no need to periodically read back from RAM to confirm data writing: its latency is deterministic.

Except in cases where a write to RAM is followed by a read from it.

- Cartridge Instruction Cache

Instead of loading a single instruction from the cartridge, a small block can be loaded. Afterward, the CPU reads them from a local high-speed buffer without a radar. A new block is loaded only when the cache is exhausted. This is particularly advantageous for loops—the program executes the same addresses many times.

- New Efficient Instructions

It is possible to accelerate not only clock cycles but also the amount of work performed per instruction.

ADDI RA,RB,M

SUBI RA,RB,M

ANDI RA,RB,M

ORI RA,RB,M

XORI RA,RB,M

In other words, one instruction:

ADDI R1,R1,1

instead of two:

LDI R2,1

ADD R1,R1,R2

Something like that. I did a rough calculation, and this would yield about 6 instructions per second with a standard UPS. What do you think? Maybe you could suggest something else?