Day 54: Build the ISS (part 2): pass rv32ui riscv-tests + run compiled C
Pass riscv-tests and run compiled C
The rv32ui suite (part of the official riscv-tests) is a set of small assembly programs, each exercising one instruction's corner cases and signaling pass/fail via a known convention. Getting your ISS to load and pass all of rv32ui is objective, external proof of correctness — far stronger than 'it looked right when I traced it'. Wire it into a make test that runs the whole suite and reports.
# assemble a test (or use prebuilt ELFs), load into the ISS, run to completion
for t in rv32ui/*.elf; do
python run_iss.py "$t" # returns 0 on PASS, nonzero on FAIL
done
# Makefile target
# test:
# @python run_suite.py rv32ui/ && echo "ALL PASS"Then run a compiled C program: your bare-metal binary from Day 38, loaded and executed to completion, with output via a UART-model stub (writes to a memory-mapped address that the ISS prints). Seeing hello emerge from a program *you compiled* running on a CPU *you wrote* is the Stage-1 payoff — and it confirms the ISS handles real compiler output (calls, stack, loops), not just handwritten tests.
A CI-style make test, from Day 54
The roadmap wants a CI-style make test now, not in Stage 3. Building that habit early means every later change to the ISS (and later the RTL) is instantly checked against rv32ui — the same regression discipline that catches bugs before they reach an interview demo or a real CI pipeline.
Key terms
- riscv-tests / rv32ui
- The official RISC-V test suite; rv32ui covers the base user-level integer instructions.
- UART-model stub
- A memory-mapped address the simulator treats as console output, letting programs print.
- make test
- A one-command regression target running the whole suite and reporting pass/fail.
- Bare-metal binary
- A self-contained program with no OS, loadable directly into the ISS or ChipX.
Ship for Day 54
Why is passing rv32ui stronger evidence than manually tracing a few programs?
