One page, one change: E bases are I bases with 16 registers (x0–x15, x0 still hardwired zero). Encodings are bit-identical to RV32I/RV64I; every encoding naming x16–x31 is reserved — not custom, not aliased. Standard extensions remain compatible unless they say otherwise (the notable exception: the H extension explicitly requires full I).
The real cost is ABI, not hardware: with only 16 registers the calling convention has fewer argument and saved registers, so E and I binaries are not link-compatible — a toolchain decision, not a decoder one. Note that the C extension already anticipated small register files: its three-bit register fields address x8–x15, which is why compressed code density survives the cut intact.
Hardware Designer Notes
For a Linux-bootable core this chapter is a non-event — Linux requires full I (glibc, the ABI, and H all assume 32 registers). E matters when you’re also dropping an M-mode-only microcontroller companion core into the same SoC and want it tiny.
Minimal Linux-boot hart MUST
- Trap any register specifier with bit 4 set as an illegal instruction — one OR-gate per specifier field feeding the decoder’s reserved detection
- Keep x0 semantics and all I-base behavior otherwise unchanged
MAY simplify / trap-and-emulate
- Physically implement a 16-entry register file (the point of the exercise) — or gate off the upper half of an existing 32-entry design
Check yourself — RV32E/RV64E
1.An RV32E core decodes ADD x20, x1, x2. What must happen?
2.What does cutting x16–x31 actually buy, per the spec's measurements?