Zalasr fills the atomic roster’s hole: standalone atomic loads and stores carrying acquire/release annotations — the exact shape C++ memory_order_acquire and Java volatile want.
This is the extension that makes RISC-V’s C++ atomics codegen look like AArch64’s LDAR/STLR: true unidirectional fences replacing lw-plus-fence idioms, with Zaamo + Zabha + Zalasr making every C++ atomic a one-instruction affair.
The atomic-extension roster had a hole: AMOs always
read-modify-write; LR/SC come as a mated pair. Nothing
offered a single atomic load or store carrying an ordering
annotation — exactly what C++ load(memory_order_acquire) and Java
volatile want. Zalasr fills it; together Zaamo + Zabha + Zalasr make
every C++ atomic operation a one-instruction affair, replacing
lw; fence r,rw idioms with true unidirectional fences.
Store-release mirrors it: funct5 00111, rd = 0, rl
mandatory, aq optional — sb/sh/sw/sd.{rl, aqrl}, storing the low
bits of rs2. Annotations are RCsc throughout: loads are always
acquire-RCsc, stores always release-RCsc, and the optional second bit
adds the other direction.
Misalignment raises address-misaligned — or access-fault when the access must not be emulated (a trap handler can’t fake atomicity with two loads). The misaligned-atomicity-granule PMA can relax this: if all bytes sit in one granule, the access proceeds as a single RVWMO memory operation.
- Load-acquire mandates aq (aq=0 is reserved), store-release mandates rl; the optional second bit makes the seq_cst forms, and every annotation is RCsc.
- The reserved corners are principled: an annotation-free atomic load is just an aligned ordinary load, and load-release / store-acquire appear in no language memory model.
- The cost scales with ambition: a couple of LSU stall conditions in-order; one-direction speculation fences out-of-order — vastly cheaper than FENCE’s full-pipeline drain.
Hardware Designer Notes
For an in-order core the cost is a couple of stall conditions in the LSU. For out-of-order, acquire/release become speculation fences on one queue direction each — vastly cheaper than the full-pipeline drain of FENCE. This is the extension that makes RISC-V’s C++ atomics codegen look like AArch64’s LDAR/STLR.
Minimal Linux-boot hart MUST
- Enforce the ordering in the load/store queue: acquire = no younger memory op issues before the load completes; release = all older ops globally visible before the store — the same machinery your AMO aq/rl already uses, on standalone ops
- Trap the reserved encodings (aq=0 loads, rl=0 stores) as illegal
MAY simplify / trap-and-emulate
- Implement conservatively as fence+op+fence internally — correct, just leaving the unidirectional performance on the table
- Support only Zalasr without Zaamo/Zalrsc (it stands alone architecturally), though the point is completing the trio
Check yourself — Zalasr
1.What gap does Zalasr fill that Zaamo and Zalrsc together leave open?
2.Why is lb.rl (load-release) not encodable — the aq bit being mandatory on loads?
3.What ordering strength do Zalasr annotations carry?