Does AMOXOR.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.
AMOXOR.H
RISC-V AMOXOR.H Instruction Details
Instruction ManualAMO-typeAMOXOR.H atomically reads the old halfword, sign-extends it into rd, and bitwise-XORs the old halfword with rs2[15:0] and writes the result.
Instruction Syntax
amoxor.h rd, rs2, (rs1)
Operand Breakdown
rd: receives the old memory value read atomically; for AMOCAS, its pre-execution value also supplies the compare value.
rs1: directly supplies the atomic-memory address; AMO assembly syntax has no offset immediate field.
rs2: supplies the AMO source data; for AMOCAS, it is the swap value stored when the comparison matches.
AMO-type is this site's presentation label for the AMO-specific R-type field layout: funct5, aq, rl, rs2, rs1, funct3, rd, and the AMO opcode encode the operation.
ZabhaAtomic
Instruction Behavior
AMOXOR.H is a Zabha (and therefore Zaamo) halfword AMO. It atomically reads the old 16-bit value at rs1, sign-extends it into rd, then writes old_halfword XOR rs2[15:0]; aq/rl annotate memory ordering.
AMOXOR.H Atomic Decode And Execute Animation
Shows Zabha (requires Zaamo) halfword atomic field decode, aq/rl ordering bits, a memory read, and RMW state update.
rd
rs2
rs1
amoxor.h,,()
Execution Context
31..27
26
25
24..20
19..15
14..12
11..7
6..0
00100
funct5
0
aq
0
rl
01011
rs2
01010
rs1
001
funct3
00101
rd
0101111
opcode
Atomic Data Path
instruction
0x20B512AF
opcode
0101111 -> AMO
funct3
001 -> halfword width
funct5
00100 -> AMOXOR.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 -> 0x0006
rd / memory
t0(x5) = 0x00000005; mem[0x00001000] = 0x0006
Current Step
Concept Step: receive the 32-bit atomic instruction encoding
Zabha depends on Zaamo; Zabha-extension halfword atomic instructions use a 32-bit encoding; the animation starts by splitting the fields.
encoding: 0x20B512AF
syntax : amoxor.h t0(x5), a1(x11), (a0(x10))
result : t0(x5) = 0x00000005; mem[0x00001000] = 0x0006
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
AMOXOR.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-XORs 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.
Zabha depends on Zaamo; rs2 contributes only its low 16 bits. Normally the address is naturally aligned to 2 bytes; with a qualifying misaligned atomicity granule PMA, it does not raise an exception solely for address alignment. aq/rl only affect memory-ordering semantics.
Common Usage Scenarios
Atomic & Sync
Understand this scenario with real code like «amoxor.h a0, a2, (a1)».
Pre-Use Checklist
Syntax Check
- Confirm the current instruction format is AMO-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.
AMOXOR.H is a 16-bit bitwise operation; it is not a 32-bit word AMO over neighboring bytes or halfwords.
Normally the target address is naturally aligned to 2 bytes; when a misaligned atomicity granule PMA is present and all accessed bytes lie in one granule, it does not raise an exception solely for address alignment. aq/rl does not change the data computation.
FAQ
How much memory does AMOXOR.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.