DEV Community: olayiwolaosho

Part 3 — Building the Control Unit: The Brain of the Datapath

olayiwolaosho — Mon, 09 Jun 2025 20:10:16 +0000

This is the third component in our emulator build. Like the ALU, the Control Unit is part of the Execute stage in the classic 5-stage MIPS instruction flow:

Fetch → Decode → Execute → Memory → Write Back

We're still working with the single-cycle processor model, which isn’t used in modern CPUs due to performance limitations, but it's incredibly useful for understanding how pipelined designs work later on. every instruction completes in one clock cycle. This means all components—memory, ALU, registers—must be ready to do their job in the same moment.

What Does the Control Unit Do?

The Control Unit takes the 6-bit opcode (bits [31–26] of the instruction) and uses it to generate 9 control signals. These signals determine:

Which data paths should be enabled or blocked
Which parts of the datapath (register file, ALU, memory, etc.) should be active
What kind of operation the ALU should perform

it basically orchestrates the data flow across the CPU.

Understanding the Control Logic

All instructions (R-type, lw, sw, beq, etc.) are fetched in the same way. After fetch, we extract common fields from the 32-bit instruction:

[31–26]: opcode
[25–21]: rs
[20–16]: rt
[15–11]: rd
[15–0]: immediate

Although instruction formats differ, we parse all instructions into these common slices, and rely on the Control Unit to make sense of what parts matter.

Example: `RegDst` for R-type vs `lw`

In an R-type instruction like add $t1, $t2, $t3, we are writing the result to the rd field ([15–11]). In contrast, for a lw instruction, the destination register is in the rt field ([20–16]).

So how do we know which register field to use?

This is where the control signal RegDst comes in:

RegDst = 1 → use [15–11] (rd) → for R-type
RegDst = 0 → use [20–16] (rt) → for lw

The control unit activates the correct data path using this signal.

Another Example: `ALUSrc` for R-type vs `lw`

The ALU takes two operands. But the source of the second operand depends on the instruction type:

R-type → both operands come from registers
lw, sw → second operand comes from the immediate field

To handle this, the control signal ALUSrc determines the ALU input source:

ALUSrc = 0 → second ALU input comes from rt register
ALUSrc = 1 → second ALU input comes from the sign-extended immediate

This lets us reuse the same ALU circuit for both instruction types, just by rerouting the inputs.

image from the book computer organisation and design detailing the R-type instructions flow

Control Signal Summary

Here are the 9 control signals and what they control:

Signal	Purpose
`RegDst`	Selects between `rd` and `rt` for write reg
`ALUSrc`	Selects ALU second input (reg vs immediate)
`MemtoReg`	Selects memory output or ALU result to write
`RegWrite`	Enables register write
`MemRead`	Enables memory read
`MemWrite`	Enables memory write
`Branch`	Enables PC update on `beq`
`ALUOp1/0`	Encodes ALU operation intent

The Code

Here's the full control unit code:

#include <stdint.h>

// Opcodes
#define R_FORMAT 0b000000
#define LW       0b100011
#define SW       0b101011
#define BEQ      0b000100

// Control values
#define ZERO     0b01
#define ONE      0b11
#define DONT_CARE 0b00

// Control signals stored here
static struct Control_Signals {
    uint8_t RegDst;
    uint8_t ALUSrc;
    uint8_t MemtoReg;
    uint8_t RegWrite;
    uint8_t MemRead;
    uint8_t MemWrite;
    uint8_t Branch;
    uint8_t ALUOp1;
    uint8_t ALUOp0;
} control_signals;

// R-type instruction setup
static void set_r_format() {
    control_signals.RegDst   = ONE;
    control_signals.ALUSrc   = ZERO;
    control_signals.MemtoReg = ZERO;
    control_signals.RegWrite = ONE;
    control_signals.MemRead  = ZERO;
    control_signals.MemWrite = ZERO;
    control_signals.Branch   = ZERO;
    control_signals.ALUOp1   = ONE;
    control_signals.ALUOp0   = ZERO;
}

// Load Word
static void set_lw() {
    control_signals.RegDst   = ZERO;
    control_signals.ALUSrc   = ONE;
    control_signals.MemtoReg = ONE;
    control_signals.RegWrite = ONE;
    control_signals.MemRead  = ONE;
    control_signals.MemWrite = ZERO;
    control_signals.Branch   = ZERO;
    control_signals.ALUOp1   = ZERO;
    control_signals.ALUOp0   = ZERO;
}

// Store Word
static void set_sw() {
    control_signals.RegDst   = DONT_CARE;
    control_signals.ALUSrc   = ONE;
    control_signals.MemtoReg = DONT_CARE;
    control_signals.RegWrite = ZERO;
    control_signals.MemRead  = ZERO;
    control_signals.MemWrite = ONE;
    control_signals.Branch   = ZERO;
    control_signals.ALUOp1   = ZERO;
    control_signals.ALUOp0   = ZERO;
}

// Branch if Equal
static void set_beq() {
    control_signals.RegDst   = DONT_CARE;
    control_signals.ALUSrc   = ZERO;
    control_signals.MemtoReg = DONT_CARE;
    control_signals.RegWrite = ZERO;
    control_signals.MemRead  = ZERO;
    control_signals.MemWrite = ZERO;
    control_signals.Branch   = ONE;
    control_signals.ALUOp1   = ZERO;
    control_signals.ALUOp0   = ONE;
}

// Main control function
void control_unit(int8_t op_code) {
    switch (op_code) {
        case R_FORMAT: set_r_format(); break;
        case LW:       set_lw();       break;
        case SW:       set_sw();       break;
        case BEQ:      set_beq();      break;
        default:
            // Leave as is for unsupported ops
            break;
    }
}

// Accessor functions
uint8_t get_RegDst()     { return control_signals.RegDst; }
uint8_t get_ALUSrc()     { return control_signals.ALUSrc; }
uint8_t get_MemtoReg()   { return control_signals.MemtoReg; }
uint8_t get_RegWrite()   { return control_signals.RegWrite; }
uint8_t get_MemRead()    { return control_signals.MemRead; }
uint8_t get_MemWrite()   { return control_signals.MemWrite; }
uint8_t get_Branch()     { return control_signals.Branch; }
uint8_t get_ALUOp1()     { return control_signals.ALUOp1; }
uint8_t get_ALUOp0()     { return control_signals.ALUOp0; }

Building a MIPS Emulator: Part 2 – The ALU

olayiwolaosho — Wed, 04 Jun 2025 00:14:58 +0000

Quick Refresher on MIPS Instruction Format

A MIPS instruction is 32 bits. For R-type instructions:

| op (6) | rs (5) | rt (5) | rd (5) | shamt (5) | funct (6) |

op (bits 31–26): the opcode (should be 000000 for R-type)
funct (bits 5–0): defines the actual operation (e.g., add, subtract)

For I-type instructions (like lw, sw, beq):

| op (6) | rs (5) | rt (5) | immediate (16) |

The op field (bits 31–26) is used directly to determine the ALU operation in this case.

ALU Operation Code Mapping

Here’s how I use the 2-bit alu_op to decide what kind of operation we’re doing:

0b00 → Add
- Used for load/store and branch offset computation
0b01 → Subtract
- Used for branch-equal (beq) to compare register values
0b10 → R-type instructions
- The actual operation is determined by the function field

Function Field Mapping (for R-type with `alu_op = 0b10`):

`funct` (6-bit)	Operation	ALU Control (4-bit)
`100000`	Add	`0010`
`100010`	Subtract	`0110`
`100100`	AND	`0000`
`100101`	OR	`0001`
`101010`	Set on Less Than	`0111`

Design Decisions

I'm currently using int32_t instead of uint32_t for register values. This is intentional — I want to allow overflow behavior (which can happen in real MIPS instructions like add), and I want this emulator to remain simple and educational.

The ALU control returns a 4-bit signal that determines which operation the ALU will execute.

Here's the Code

#include <stdint.h>
#include <stdio.h>

uint8_t get_alu_ops_from_funct_field(uint8_t funct_field);

// Generates a 4-bit control signal for the ALU
uint8_t alu_control(uint8_t alu_op, uint8_t funct_field) {
    alu_op &= 0b11;

    switch (alu_op) {
        case 0b00:
            return 0b0010;  // ADD
        case 0b01:
            return 0b0110;  // SUB
        case 0b10:
            return get_alu_ops_from_funct_field(funct_field & 0b111111);
        default:
            printf("Invalid ALU op: 0x%02X\n", alu_op);
            return -1;
    }
}

uint8_t get_alu_ops_from_funct_field(uint8_t funct_field) {
    switch (funct_field) {
        case 0b100000: return 0b0010; // ADD
        case 0b100010: return 0b0110; // SUB
        case 0b100100: return 0b0000; // AND
        case 0b100101: return 0b0001; // OR
        case 0b101010: return 0b0111; // SLT
        default:
            printf("Invalid funct field: 0x%02X\n", funct_field);
            return -1;
    }
}

// Performs the actual ALU operation
int32_t alu(int32_t reg_s1, int32_t reg_s2, uint8_t alu_op, uint8_t funct_field) {
    switch (alu_control(alu_op, funct_field)) {
        case 0b0010: return reg_s1 + reg_s2;
        case 0b0110: return reg_s1 - reg_s2;
        case 0b0000: return reg_s1 & reg_s2;
        case 0b0001: return reg_s1 | reg_s2;
        case 0b0111: return reg_s1 < reg_s2;
        default:
            printf("Invalid ALU control signal.\n");
            return 0;
    }
}

Final Note

This ALU implementation is a starting point and will likely evolve as I learn more and expand the emulator. I’m keeping things modular and easy to follow for now.

Building a MIPS Emulator (Part 1): Loading and Reading Raw Binary

olayiwolaosho — Sun, 18 May 2025 22:53:45 +0000

"I didn’t know how anything would work when I started—just had a vague sense I’d figure it out along the way."

Why I’m Doing This

I wanted to understand how computers really work—beyond just writing high-level code. I needed to deepen my knowledge and prove to myself that these low-level systems aren’t inherently difficult; you just need the right concepts.

So, I decided to build a MIPS emulator.

I broke it down into three parts:

Loading the binary code from a MIPS program
Decoding the binary instructions
Executing them

At first, I didn’t even know how to load a file, let alone parse instructions. So that’s where I began.

Step 1: Getting the Binary File

We need a binary file that contains MIPS instructions in raw binary format. There are other formats like ELF, but I chose to keep it simple with a .bin file.

Fun fact: I didn’t know until recently that .bin files can directly contain raw binary instructions. You learn something new every day.

To generate one, I used MARS 4.5, a MIPS simulator written in Java. I wrote a simple program:

addiu $t0, $zero, 5    # $t0 = 5  
addiu $t1, $zero, 7    # $t1 = 7  
addu  $t2, $t0, $t1    # $t2 = $t0 + $t1

Then I assembled it and used File → Dump Memory to export the instructions. Make sure you:

Set the format to Binary
Save it with a .bin extension

Step 2: Reading the Binary File in C

Once I had the .bin file, I wrote a simple C program to read and print each 32-bit MIPS instruction. Here's a snippet:

FILE *file = fopen(filename, "rb");

if (!file) {
    perror("Failed to open file");
    return 1;
}

The "rb" mode means we’re opening the file for reading in binary mode. If the file doesn’t exist, fopen() returns NULL.

Then I read the file 4 bytes at a time (since MIPS instructions are 32-bit = 4 bytes):

while (fread(&instruction, sizeof(u_int32_t), 1, file) == 1) {
    printf("0x%08X | 0x%08X          | %u\n", offset, instruction, instruction);
    offset += 4;
}

I set the counter to one so I could overwrite whatever was in the instruction and store the value read from the file stream

Full Code

#include <stdio.h>
#include <stdint.h>

int loadMipsBinary(const char *filename) {
    FILE *file = fopen(filename, "rb");

    if (!file) {
        perror("Failed to open file");
        return 1;
    }

    printf("Address (byte offset)  | Instruction (Hex)  | Instruction (Dec)\n");
    printf("-----------------------|---------------------|---------------------\n");

    uint32_t instruction;
    size_t offset = 0;

    while (fread(&instruction, sizeof(uint32_t), 1, file) == 1) {
        printf("0x%08X               | 0x%08X          | %u\n",
               (unsigned int)offset, instruction, instruction);
        offset += 4;
    }

    fclose(file);
    return 0;
}

int main() {
    loadMipsBinary("mipstest.bin");
    return 0;
}

Let me know when you're ready for Part 2—decoding the binary into actual MIPS operations.