The chronological rationale appendix: four entries so far, each recording the concrete software cost an extension removed — the “considered X, chose Y because Z” ledger.
It doubles as a design-review lens: does a proposed custom instruction remove a concrete, measured cost, or is it speculative? The appendix models the standard.
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. |
- PAUSE survived the MONITOR/MWAIT debate because cpu_relax polls for unknown events — and Zawrs later added the single-address wait.
- Zicond’s two-source primitives exist because a select needs three sources and a cmov costs the same under register renaming.
- Zacas and Zabha entries close real hazards: 128-bit CAS for ABA, native subword atomics because the emulation side effects were measured, not hypothetical.
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?