Can LW.AQ use offset(rs1)?
No. The syntax is lw.aq rd, (rs1); rs1 supplies the address, with no offset field.
LW.AQ
RISC-V LW.AQ Instruction Details
Instruction ManualAMOZalasr atomic load of 4 bytes with acquire-RCsc ordering.
Instruction Syntax
lw.aq rd, (rs1)
rd: receives the loaded value sign-extended to XLEN; rd=x0 discards only writeback while retaining load exceptions and side effects.
rs1: supplies the pre-execution address directly, with no offset immediate. rs1=x0 gives address zero; rd=rs1 still uses the address before writeback.
The rs2 field is fixed to 00000 and is not an assembly operand. aq=1, while .aq or .aqrl selects rl; both bits specify ordering annotations only.
ZalasrCache & Synchronization
Instruction Behavior
LW.AQ is a 4-byte ordered atomic load in the Zalasr 1.0 standalone load-acquire/store-release family. It atomically reads 32 bits from the address in x[rs1], sign-extends from that width, and writes x[rd]; the syntax has no offset field. The address is naturally aligned to the access width by default unless relaxed by the misaligned atomicity granule PMA.
LW.AQ Zalasr Decode And Execute Animation
Shows the Zalasr standalone load-acquire AMO encoding, no-offset address syntax, 32-bit data transfer, and aq/rl ordering annotation.
rd
rs1
lw.aq,()
Execution Context
Ordering Annotation
aq=1, rl=0 (acquire)
For an address not naturally aligned to 4 bytes, the checkbox only asserts that all accessed bytes lie in one misaligned atomicity-granule PMA. Without that assertion, the model shows the permitted address-misaligned or access-fault branch; it does not determine a platform's PMA.
Assume implemented Zalasr and successful permitted fetch/data access except for the shown alignment exception. Address samples are nonnegative safe integers (at most 2^53−1), also fitting 32 bits on RV32; this is a demo input limit. rd=x0 still performs the load and its side effects, discarding only the result; rd=rs1 uses the address before writeback.
31..27
26
25
24..20
19..15
14..12
11..7
6..0
00110
funct5
1
aq
0
rl
00000
rs2=00000
01010
rs1
010
funct3
00101
rd
0101111
opcode
Zalasr Data Path
instruction
0x340522AF
opcode
0101111 -> AMO major opcode
funct5
00110 -> LW.AQ
aq / rl
1/0 -> acquire
operands
rd=t0(x5), rs1=a0(x10)
address
a0(x10) -> 0x00001000 (no offset); naturally aligned
memory read
mem[0x00001000] -> 0x80000002
execute
sign_extend(0x80000002, 32) -> 0x80000002
writeback
t0(x5) = 0x80000002
32-bit Transfer View
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
memory 32
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
LW.AQ loads 32 bits from memory and sign-extends from that width to XLEN before writing rd.
This animation shows ISA-visible Zalasr atomic load/store behavior and aq/rl ordering annotations; it does not model LR/SC reservations, AMO read-modify-write old-value return, caches, buses, or pipeline timing.
Quick Understanding & Search Notes
LW.AQ uses rs1 directly as the address, atomically reads 4 bytes, and sign-extends into rd; aq/rl bits provide ordering annotations and do not change the loaded data.
The syntax is lw.aq rd, (rs1), with no offset field; the address comes from x[rs1].
32-bit AMO encoding: funct5[31:27]=00110, aq[26]=1, rl[25]=0, rs2[24:20]=00000, rs1[19:15], funct3[14:12]=010, rd[11:7], opcode[6:0]=0101111.
The 32-bit loaded value is sign-extended from the source width to XLEN.
LW.AQ has aq=1 and rl=0: it has acquire-RCsc, not release-RCsc, annotation. aq/rl do not change the load, sign extension, or rd=x0 architectural behavior.
Requires implemented Zalasr 1.0; this form supports RV32/RV64. The address must be naturally 4-byte aligned, otherwise an address-misaligned or access-fault exception is generated. If all accessed bytes lie in one misaligned atomicity-granule PMA, no address-alignment exception is raised and atomicity is retained.
rd=x0 discards only writeback; the load must still cause exceptions and other side effects. rs1=x0 means address zero. When rd=rs1, the address uses the register value before writeback.
Example: assume implemented Zalasr and successful permitted fetch/data access. On RV32, with x6=0x1000 and the 32-bit memory value 0x80000002, lw.aq x5, (x6) gives x5=0x80000002; memory is unchanged. On RV64 the same value sign-extends to 0xFFFFFFFF80000002.
Common Usage Scenarios
Atomic & Sync
Understand this scenario with real code like «lw.aq x5, (x6)».
Concurrency & Multi-core
Understand this scenario with real code like «lw.aq x5, (x6)».
Pre-Use Checklist
Syntax Check
- Confirm the current instruction format is AMO.
- Confirm the operand order matches the example.
Semantic Check
- Ensure the destination register usage is compatible with the calling convention.
- Confirm this is not the lower-level form of a pseudo-instruction expansion.
Pitfalls / Common Confusions
The syntax has no offset immediate; the address comes directly from rs1.
The load result is sign-extended from the 32-bit source width to XLEN; Zalasr has no unsigned load form.
Zalasr load encodings without aq set are RESERVED.
Zalasr is a standalone ordered atomic load; it does not use LR/SC reservations or perform AMO read-modify-write.
FAQ
Is LW.AQ an LR/SC or AMO read-modify-write operation?
No. It is an atomic load, with neither a reservation nor a read-modify-write.
Do aq/rl bits change the data result?
No. aq/rl are ordering annotations; the loaded value is still sign-extended from the source width into rd.