The last two reference entries, and the exit summary for the whole chapter.
| Semantics | Encoding | In | |
|---|---|---|---|
| zext.h rd, rs | Zero-extend the low halfword. | funct7 0000100, rs2=00000, funct3 100 — OP (RV32) / OP-32 (RV64) | Zbb |
| zip rd, rs (RV32, detailed with unzip on the previous page) | Bit-interleave the two halves of rs. | OP-IMM funct12 0000100_01111 / 001 | Zbkb |
The chapter in one table
| Hardware cost | Payoff | |
|---|---|---|
| Zba | 3 adder mux legs + zero-extend | One instruction back per array access — the best gates-to-IPC trade in the catalog. |
| Zbb | Scan tree, rotator wrap, inverter reuse, wiring permutations | strlen/bswap/clamp/bitmap idioms; compiler-default output. |
| Zbs | One-hot decoder into the logic unit | Flag and bitfield manipulation in one op. |
| Zbc | XOR-tree multiplier (~half a MUL) | CRC/GF(2) throughput. |
| Zbkb/Zbkc/Zbkx | pack muxes, zip wiring, crossbars; clmul reuse | Constant-time cipher kernels — take them with the Zk scalar-crypto bundle. |
Hardware Designer Notes
Done: 51 instructions, roughly one afternoon of datapath and a week of decode verification, for the single largest code-density and string-performance jump available to an RV64 core. The consistency pass for this chapter (and the cross-check against the u36 opcode listings) runs next.
Minimal Linux-boot hart MUST
- Implement Zba + Zbb + Zbs (= B) for any Linux-class core: RVA23 mandates them and distro binaries assume them
- Decode zext.h’s fixed-rs2 point exactly — a nonzero rs2 there is pack (Zbkb), a different instruction
MAY simplify / trap-and-emulate
- Stage the crypto subsets with your Zk plans; nothing in the base OS stack requires them
Check yourself — zext.h & the bitmanip wrap-up
1.zext.h has its own dedicated encoding while zext.b and zext.w don't. Why?
2.Which Zb* subsets does a Linux-class application core actually need?
2 questions