"Zalasr": Load-Acquire & Store-Release

Part III Linux boot: optional Vol. I (Unprivileged) pp. 82–84 · ~2 min read

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.

001103127aq=126rl25000002420rs11915width1412rd117010111160Load-Acquire: lb/lh/lw/ld.{aq, aqrl} (AMO opcode)
Click a field for its role.

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.

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?

3 questions