One page that changes no instructions and everything else: RVTSO is RVWMO with the ordering dial turned to x86. Its two audiences — code ported from x86/SPARC without re-auditing every fence, and implementations that are inherently TSO (a strongly- ordered memory system) wanting credit for it.
| As-if annotation | |
|---|---|
| Every load | acquire-RCpc — no later memory op moves before it. |
| Every store | release-RCpc — no earlier memory op moves after it. |
| Every AMO | acquire-RCsc AND release-RCsc — a full two-way barrier; nothing reorders past an AMO in either direction. |
Consequences the spec draws: all PPO rules except 4–7 become redundant, as does any non-I/O FENCE lacking both PW and SR. What survives is the one relaxation every TSO model keeps: the store buffer — a hart may forward its own pending stores to its own later loads before any other hart can see them. That’s the complete visible difference from sequential consistency.
Vector memory instructions follow RVTSO at instruction granularity; ordering among a single instruction’s element accesses is not strengthened.
The compatibility trap: a binary compiled for TSO omits fences that RVWMO requires, so it silently misbehaves on weaker cores. Such binaries must carry a flag (the ELF TSO marker) so non-Ztso platforms refuse them. The reverse direction is safe — RVWMO binaries only find extra ordering on a Ztso machine.
Hardware Designer Notes
The decision is one-way: once software ships assuming your Ztso flag, every future microarchitecture in the family inherits the promise. Weak-by-default (RVWMO) preserves your roadmap; claim TSO only if you’d bet the next three designs on it.
Minimal Linux-boot hart MUST
- If you claim Ztso: verify NO load-load, load-store, or store-store visible reordering ever escapes the hart — the claim is about your memory system, not your decoder
- Keep AMOs fully fenced both directions
MAY simplify / trap-and-emulate
- Claim Ztso when your memory system is already strongly ordered (single-issue in-order cores with blocking caches often are) — free marketing for x86-ported software
- Decline it and keep RVWMO freedom — the right call for any aggressive out-of-order memory system; do NOT claim it aspirationally
Check yourself — Ztso
1.Under RVTSO, which single hardware reordering does the model still permit?
2.Ztso adds zero instructions. Why must TSO-compiled binaries still carry an ELF flag?