Can LH.AQRL use offset(rs1)?
No. The syntax is lh.aqrl rd, (rs1); rs1 supplies the address, with no offset field.
LH.AQRL
RISC-V LH.AQRL Instruction Details
Instruction ManualAMOZalasr atomic load of 2 bytes with acquire+release-RCsc ordering.
Instruction Syntax
lh.aqrl 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
LH.AQRL is a 2-byte ordered atomic load in the Zalasr 1.0 standalone load-acquire/store-release family. It atomically reads 16 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.
LH.AQRL Zalasr Decode And Execute Animation
Shows the Zalasr standalone load-acquire AMO encoding, no-offset address syntax, 16-bit data transfer, and aq/rl ordering annotation.
rd
rs1
lh.aqrl,()
Execution Context
Ordering Annotation
aq=1, rl=1 (acquire+release)
For an address not naturally aligned to 2 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
1
rl
00000
rs2=00000
01010
rs1
001
funct3
00101
rd
0101111
opcode
Zalasr Data Path
instruction
0x360512AF
opcode
0101111 -> AMO major opcode
funct5
00110 -> LH.AQRL
aq / rl
1/1 -> acquire+release
operands
rd=t0(x5), rs1=a0(x10)
address
a0(x10) -> 0x00001000 (no offset); naturally aligned
memory read
mem[0x00001000] -> 0xFFF2
execute
sign_extend(0xFFF2, 16) -> 0xFFFFFFF2
writeback
t0(x5) = 0xFFFFFFF2
16-bit Transfer View
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
1
1
1
1
1
1
1
1
1
1
1
1
0
0
1
0
memory 16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
LH.AQRL loads 16 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
LH.AQRL uses rs1 directly as the address, atomically reads 2 bytes, and sign-extends into rd; aq/rl bits provide ordering annotations and do not change the loaded data.
The syntax is lh.aqrl 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]=1, rs2[24:20]=00000, rs1[19:15], funct3[14:12]=001, rd[11:7], opcode[6:0]=0101111.
The 16-bit loaded value is sign-extended from the source width to XLEN.
LH.AQRL has aq=1 and rl=1: it has both acquire-RCsc and release-RCsc annotations. 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 2-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 16-bit memory value 0xFFF2, lh.aqrl x5, (x6) gives x5=0xFFFFFFF2; memory is unchanged. On RV64 the same value sign-extends to 0xFFFFFFFFFFFFFFF2.
Common Usage Scenarios
Atomic & Sync
Understand this scenario with real code like «lh.aqrl x5, (x6)».
Concurrency & Multi-core
Understand this scenario with real code like «lh.aqrl 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 16-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 LH.AQRL 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.