Does PACKW access memory?
No. It concatenates low fields from rs1 and rs2 into rd, without a table lookup.
RV64 pack low 16-bit fields (Zbkb), RV64-only.
RV64 only Zbkb 1.0; syntax packw rd, rs1, rs2, selecting integer x0–x31 or ABI names, with no immediate.
32-bit R-type: funct7=0000100, funct3=100, opcode=0111011.
rd sign-extends the concatenation of rs2[15:0] above rs1[15:0], extending bit31 to 64 bits.
Read sources before writeback; equal sources have one old value, x0 sources are zero, and rd=x0 discards writeback. No memory access occurs.
PACKW (Zbkb, RV64) places rs1[15:0] into result bits [15:0], rs2[15:0] into bits [31:16], then sign-extends bit 31 into the upper 32 bits of rd.
Shows only specification-defined encodings, conditions, and architectural state; it does not model pipelines, cache coherence, or platform policy.
PACKW (Zbkb, RV64) places rs1[15:0] into result bits [15:0], rs2[15:0] into bits [31:16], then sign-extends bit 31 into the upper 32 bits of rd.
Assume RV64 Zbkb, a1=0x1122334455667788 and a2=0x99AABBCCDDEEFF80; packw a0, a1, a2 produces a0=0xFFFFFFFFFF807788, leaving sources and memory unchanged.
Assume RV64 Zbkb, a1=0x1122334455667788 and a2=0x99AABBCCDDEEFF80; packw a0, a1, a2 produces a0=0xFFFFFFFFFF807788, leaving sources and memory unchanged.
No. It concatenates low fields from rs1 and rs2 into rd, without a table lookup.
It belongs to the Zbkb cryptographic bit-manipulation extension.