Volume I’s chronological rationale appendix (started ca. 2025, the mirror of Vol II’s Appendix A), recording why recent extensions took the shape they did. Four entries so far:
| Rationale | |
|---|---|
| F.1 Zihintpause | MONITOR/MWAIT was debated but PAUSE kept: it suits polling for non-memory events, multiple events, or unknown events — the last being ubiquitous because it’s what Linux cpu_relax() expects. |
| F.2 Zicond | A conditional-SELECT needs three sources (too costly standalone); conditional-MOVE costs similarly under register renaming — so the 2-source czero.eqz/nez primitives were chosen, building select in a few instructions. |
| F.3 Zacas | Single-instruction compare-and-swap for lock-free algorithms, with register pairs for wide (64/128-bit) CAS and the 128-bit form specifically for ABA avoidance. |
| F.4 Zabha | Native byte/halfword atomics, because emulating them via wider AMOs caused NUMA fairness, non-idempotent-I/O side effects, spurious watchpoints, and code bloat. |
Hardware Designer Notes
That completes Part III — every non-core extension of both volumes, at full depth. The rationale appendices (this and Vol II’s) are the quality bar for the whole book’s Hardware Designer Notes: every design choice traced to the loophole or cost it closes. The remaining work is the site’s connective tissue — the Linux-boot roadmap, the landing page, and the cross-links that turn 153 pages into one navigable textbook.
Minimal Linux-boot hart MUST
- Nothing new — this appendix is the WHY behind extensions implemented in u09/u11/u15/u16
MAY simplify / trap-and-emulate
- Use it as a design-review lens: does a proposed custom instruction remove a concrete, measured software cost, or is it speculative? The appendix models the standard
Check yourself — Vol I rationale
1.Why did the designers keep PAUSE rather than adopting an x86-style MONITOR/MWAIT?
2.The Zicond rationale explains why RISC-V has czero.eqz/nez instead of a conditional-move. What's the argument?