How do C.LH and C.LHU differ?
Both read 16 bits at base plus 0 or 2 bytes. C.LH sign-extends and C.LHU zero-extends: on RV64, 0x8001 gives 0xffffffffffff8001 and 0x8001 respectively.
C.LH
RISC-V C.LH Instruction Details
Instruction ManualC-typeRV32/RV64 Zcb 16-bit halfword load: offset 0 or 2 bytes; sign-extend the 16-bit value to XLEN.
Instruction Syntax
c.lh rd', uimm(rs1')
Operand Breakdown
RV32/RV64 Zcb requiring Zca; 16-bit CLH format. C alone does not provide this instruction.
Three-bit rd' and rs1' select x8–x15; the byte offset is only 0 or 2, with inst[5] supplying uimm[1].
A completed 16-bit halfword load is sign-extended to XLEN; use the base before writeback.
Two-byte addresses are naturally aligned; the EEI defines misaligned outcomes. Permissions and memory-region rules still apply.
ZcbCompressed Instruction
Instruction Behavior
C.LH (Zcb, CLH format) loads a halfword from rs1' + zero-extended offset into rd', sign-extended to XLEN. rd' and rs1' limited to x8-x15. Expands to lh rd',uimm(rs1'). Offset is 1-bit unsigned ×2. Part of Zcb, depends on Zca.
C.LH Decode & Execute Animation
Shows only official 16-bit fields, address/immediate calculation, and architectural state; it does not simulate a pipeline, cache, endianness implementation, or timing.
c.lh, ()
Execution context
RV32 / RV64 Zcb (requires Zca)
An address divisible by 2 is naturally aligned, so the address-misaligned option does not apply; access faults remain possible. The EEI defines misaligned completion. Memory values are already interpreted using EEI endianness.
x[rs1'] + 2 -> 0x0000000000002002; sext(mem[0x0000000000002002][15:0] = 0x8001) = 0xFFFFFFFFFFFF8001
16-bit encoding fields
15..10
funct6
100001
9..7
rs1'
010
6
bit 6: signed
1
5
uimm[1]
1
4..2
rd'
001
1..0
op
00
Execution data path
Compressed fields: rd'=001 -> x9, rs1'=010 -> x10, uimm=2. inst[5] -> uimm[1]; other bits=0 -> 2 bytes (EXTZ)
(0x0000000000002000 + 2) mod 2^64 = 0x0000000000002002
sext(mem[0x0000000000002002][15:0] = 0x8001) = 0xFFFFFFFFFFFF8001
Architectural state has not been committed.
Quick Understanding & Search Notes
RV32/RV64 Zcb 16-bit halfword load: offset 0 or 2 bytes; sign-extend the 16-bit value to XLEN.
CLH: inst[5] supplies uimm[1]; all other offset bits are zero. Inst[6] distinguishes signed and unsigned loads.
A completed access sign-extends to XLEN; natural alignment is two bytes and the EEI defines misaligned outcomes.
Common Usage Scenarios
Halfword data load
RV64 Zcb, x10=0x2000 and mem16[0x2002] = 0x8001, with a completed access: c.lh x9, 2(x10) gives x9 = 0xffffffffffff8001; RV32 gives 0xffff8001.
Pre-Use Checklist
Syntax Check
- RV32/RV64 Zcb requiring Zca; 16-bit CLH format. C alone does not provide this instruction.
- Three-bit rd' and rs1' select x8–x15; the byte offset is only 0 or 2, with inst[5] supplying uimm[1].
Semantic Check
- A completed 16-bit halfword load is sign-extended to XLEN; use the base before writeback.
- Two-byte addresses are naturally aligned; the EEI defines misaligned outcomes. Permissions and memory-region rules still apply.
Pitfalls / Common Confusions
Three-bit rd' and rs1' select only x8–x15.
The offset is 0 or 2 bytes; the base can still make the effective address misaligned.
Sign-extend the 16-bit load to XLEN. Zcb requires Zca; C alone does not provide this instruction.
FAQ
Does an even offset guarantee no trap?
No. An odd base makes the effective address misaligned; even naturally aligned accesses must meet the EEI memory-region and permission rules.