Machine mode is where your CPU boots, traps, and tells the world what it is. This chapter (Vol II’s longest) specifies all of it; we start with the hart’s self-description registers.
3.1.1 misa: what this hart speaks
misa (0x301, MXLEN=64 shown)
(The spec’s own figure for misa is one of the priv PDF’s missing diagrams — layout reconstructed from the field text, as flagged in this book’s source notes.)
The interesting semantics are all about writable misa:
| Rule | |
|---|---|
| Disabling | Clearing a bit makes the extension NOT IMPLEMENTED — encodings revert to reserved (not necessarily illegal) behavior |
| Dependencies | Enabling x while disabling its dependency y clears both: F=0∧D=1 → F=D=0; U=0∧S=1 → S=U=0. Combos may legalize as one collective WARL field |
| IALIGN hazard | A write that would raise IALIGN (clearing C) while the NEXT instruction is misaligned is SUPPRESSED — misa unchanged |
| Re-enabling | State uniquely owned by a re-enabled extension is UNSPECIFIED — treat as garbage and reinitialize |
| E bit | Read-only complement of I (unless misa = 0 entirely); selecting RV32E = clearing I where both are supported |
3.1.2–3.1.5 The identity block (all read-only, all may be zero except one rule)
| Holds | Constraint | |
|---|---|---|
| mvendorid (32-bit) | JEDEC manufacturer ID: Bank = number of 0x7f continuation bytes, Offset = final byte sans parity | 0 = non-commercial / unimplemented |
| marchid (MXLEN) | Microarchitecture ID | MSB=0: open-source IDs allocated globally by RISC-V International; MSB=1: vendor-managed commercial IDs |
| mimpid (MXLEN) | Implementation (version) ID, vendor-formatted | 0 legal; left-justified nibble convention recommended |
| mhartid (MXLEN) | This hart’s ID | Unique per hart; EXACTLY ONE hart must be 0; contiguity not required |
Hardware Designer Notes
The pragmatic v1: hardwire misa to your shipped configuration and all three ID registers to 0 (or your JEDEC/marchid once registered); mhartid comes from a per-hart input strap. Writable-misa dynamics (suppression, dependency clearing, UNSPECIFIED-on-reenable) are a verification tax that buys little on a fixed-function core.
Minimal Linux-boot hart MUST
- Make misa readable (zero allowed); if writable, implement the dependency and IALIGN-suppression rules exactly
- Give every hart a unique mhartid with exactly one zero
MAY simplify / trap-and-emulate
- Hardwire everything on this page — a fixed-configuration Linux core loses nothing
- Return 0 in mvendorid/marchid/mimpid until you have registered IDs
Check yourself — misa & identity
1.Software writes misa with F=0 but D=1. What does misa read back?
2.M-mode code at a 16-bit-aligned (not 32-bit-aligned) PC writes misa to clear C. What happens?
3.After clearing misa.F, do FP instructions necessarily raise illegal-instruction?
4.Which identity CSR value is architecturally constrained across a multi-hart system?