SHA-512 operates on 64-bit words — which fit an RV64 register but not an RV32 one. So Zknh presents two faces: single unary transforms on RV64, and high/low half-operations on RV32 that synthesize each 64-bit function from a register pair.
| Instruction(s) | |
|---|---|
| RV64 (native 64-bit) | sha512sig0, sha512sig1 (message-schedule σ0/σ1: three-term rotate/shift-XOR over 64 bits) and sha512sum0, sha512sum1 (round Σ0/Σ1: three rotates) — one unary instruction each, exactly the SHA-256 shape doubled. |
| RV32 message schedule | sha512sig0h/sig0l and sha512sig1h/sig1l: each pair reads two 32-bit halves (rs1, rs2) of the 64-bit word and produces one 32-bit half of σ, the rotate amounts crossing the register boundary. |
| RV32 compression rounds | sha512sum0r, sha512sum1r: the round Σ functions, likewise producing a 32-bit half from the register-pair operand. |
Hardware Designer Notes
For an RV64 Linux server, SHA-512 (and SHA-384, same instructions) is four cheap instructions covering the certificate-signing and KDF-heavy paths. RV32 IoT devices pay a 2.5× instruction-count tax for the same security — usually fine, since embedded TLS leans on SHA-256 anyway.
Minimal Linux-boot hart MUST
- RV64: four unary fixed-rotate-XOR transforms, 64-bit wide, data-independent latency
- RV32: the six half-operations, each reading two registers and producing one 32-bit half with the correct boundary-crossing rotations
MAY simplify / trap-and-emulate
- Share the SHA-256 and SHA-512 XOR-tree structure with width parameterization on RV64
- On RV32, treat the SHA-512 half-ops as a distinct decode group — their two-source shape differs from the unary SHA-256 transforms
Check yourself — SHA-512 & SHA half-ops
1.sha512sum0r on RV32 takes rs1 and rs2 (a 64-bit word split across two registers). Why two source registers when sha256sum0 needs only one?
2.On RV64, how many instructions implement SHA-512's four transform functions?