The ISA string — rv64imafdc_zicsr_zifencei and friends — is the
machine-readable contract between your core, the device tree, and every
toolchain flag. Its grammar is small but strict, and case-insensitive.
| Form | Rules | |
|---|---|---|
| 1 · Prefix | RV32 / RV64 (+ RV128 someday) | Address-space width |
| 2 · Base | I or E | Integer base; E = 16-register embedded variant |
| 3 · Single letters | M A F D (→G) Q L C B K J T P V H | Canonical order per Table 74 |
| 4 · Z* | Z + category letter + name (Zicsr, Zba, Ztso…) | Category = closest related letter; sort by category, then alphabetically |
| 5 · Ss* / Sv* | Supervisor (Ss…) and supervisor-VM (Sv39, Sv48…) | After unprivileged; alphabetical. sv39/48 predate the no-trailing-digit rule |
| 6 · Sh*, then Sm* | Hypervisor-only, then machine-level | Alphabetical within each family |
| 7 · X* | Non-standard (Xhwacha…) | Dead last, alphabetical, underscore-separated |
Name shape rule: every extension name ends in a letter — no trailing digits, and no digit immediately before a trailing “p”. That’s what makes version suffixes parseable.
Version numbers
<major>p<minor> follows the name: rv32i2p2 = RV32I v2.2; “p0” may be
dropped (i2 = v2.0); unversioned = the release-2 defaults (RV32I ≡
RV32I2). Major bump = backwards incompatibility; minor bump must be
compatible. The one ambiguity in the grammar gets a special rule:
rv32i2p2— RV32I version 2.2rv32i2_p2— RV32I v2.0 plus the P extension v2.0
P must be underscore-separated whenever it follows a versioned extension.
Hardware Designer Notes
This closes the Part I core-track chapters drawn from Vol I’s main body: the remaining Part I material is the two memory-model appendices (uA, uB). Practical tie-in: your misa register (Vol II ch. 3) advertises the single letters; the multi-letter extensions have no misa bits and exist only in the ISA string / unified discovery — one more reason the string must be exact.
Minimal Linux-boot hart MUST
- Emit a canonical-order, correctly underscored string in your platform description — parsers are strict
- Version your custom X* extensions and keep them last
MAY simplify / trap-and-emulate
- Rely on implicit dependencies (RV64IFD implies Zicsr) — but spelling them out is kinder to tooling
Check yourself — ISA naming
1.What's the difference between rv32i2p2 and rv32i2_p2?
2.Is RV32IMAVC a legal ISA string?
3.Where does your custom Xfoo extension go in rv64imac_zicsr_ssaia_xfoo?