Does AMOOR.H zero-extend rd?
No. Zabha AMO.H sign-extends the old value into rd; the U in AMOMINU.H/AMOMAXU.H only means unsigned comparison.
AMOOR.H
RISC-V AMOOR.H Instruction Details
Instruction ManualR-typeAMOOR.H atomically reads the old halfword, sign-extends it into rd, and bitwise-ORs the old halfword with rs2[15:0] and writes the result.
Instruction Syntax
amoor.h rd, rs2, (rs1)
Operand Breakdown
Destination rd: register receiving the operation result.
Source rs1: register holding the first operand.
Source rs2: register holding the second operand.
ZabhaAtomic
Instruction Behavior
AMOOR.H is a halfword AMO from the Zabha byte and halfword atomic-memory-operation extension. It performs a 16-bit read-modify-write, writes the sign-extended old memory halfword to rd, and bitwise-ORs the old halfword with rs2[15:0] and writes the result. The aq/rl bits annotate memory ordering and do not change the data computation.
AMOOR.H Atomic Decode And Execute Animation
Shows Zabha halfword atomic field decode, aq/rl ordering bits, memory read, and RMW state update.
rd
rs2
rs1
amoor.h,,()
Execution Context
31..27
26
25
24..20
19..15
14..12
11..7
6..0
01000
funct5
0
aq
0
rl
01011
rs2
01010
rs1
001
funct3
00101
rd
0101111
opcode
Atomic Data Path
instruction
0x40B512AF
opcode
0101111 -> AMO
funct3
001 -> halfword width
funct5
01000 -> AMOOR.H
aq / rl
0/0 -> unordered
rd / rs2 / rs1
t0(x5) / a1(x11)=0x0003 / a0(x10)=0x00001000
memory read
mem[0x00001000] -> old halfword 0x0005
RMW
0x0005 | 0x0003 -> 0x0007
rd / memory
t0(x5) = 0x00000005; mem[0x00001000] = 0x0007
Current Step
Concept Step: receive the 32-bit atomic instruction encoding
Zabha-extension halfword atomic instructions use a 32-bit encoding; the animation starts by splitting the fields.
encoding: 0x40B512AF
syntax : amoor.h t0(x5), a1(x11), (a0(x10))
result : t0(x5) = 0x00000005; mem[0x00001000] = 0x0007
16-bit Halfword Result View
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
1
old halfword
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
1
rs2 halfword
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
This animation shows ISA-visible atomic read-modify-write, compare-and-swap, LR/SC reservation state, and ordering bits, not any specific CPU cache-coherence implementation, pipeline, or timing.
Quick Understanding & Search Notes
AMOOR.H is an L5 Zabha halfword AMO: it atomically reads the old 16-bit memory value, sign-extends that old value into rd, and bitwise-ORs the old halfword with rs2[15:0] and writes the result.
The encoding uses AMO major opcode 0101111, funct3=001 for halfword width, and funct5 to select the specific AMO operation.
All AMO.H forms write the sign-extended old halfword to rd; the unsigned suffix only changes min/max comparison interpretation.
rs2 contributes only its low 16 bits, the address is naturally aligned to 2 bytes, and aq/rl only affect memory-ordering semantics.
Common Usage Scenarios
Atomic & Sync
Understand this scenario with real code like «amoor.h a0, a2, (a1)».
Network & Byte Order
Understand this scenario with real code like «amoor.h a0, a2, (a1)».
Pre-Use Checklist
Syntax Check
- Confirm the current instruction format is R-type.
- 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
rd receives the old memory halfword sign-extended to XLEN, not the newly written memory value.
Only the low 16 bits of rs2 participate in the halfword computation; upper rs2 bits do not affect this AMO.H data result.
AMOOR.H is a 16-bit bitwise operation; it is not a 32-bit word AMO over neighboring bytes or halfwords.
The target address must be naturally aligned for a halfword; aq/rl ordering bits do not replace the alignment requirement.
FAQ
How much memory does AMOOR.H modify?
Architecturally it modifies only the target 16-bit halfword and computes the new memory value at halfword width; neighboring bytes are not part of that data result.