§33.5 gathers the vector bit-manipulation (Zvbb) and carry-less multiply (Zvbc) instructions as a category distinct from the algorithm-specific crypto — because they are general primitives that support cryptography rather than implementing ciphers.
| Property | |
|---|---|
| General-purpose | vbrev/vrev8/vrol/vror/vandn/vwsll/vclz/vctz/vcpop (Zvbb) and vclmul/vclmulh (Zvbc) serve crypto, CRCs, compression, and generic SIMD alike. |
| Opt-in constant time | Their data-independent latency is guaranteed only under Zvkt — unlike the AES/SHA/GCM/SM instructions, which are intrinsically constant-time by definition. |
| clmul’s separate extension | Zvbc is split from Zvbb because the per-lane GF(2) multiplier is real area that can’t amortize across the cheap bit operations — mirroring scalar Zbkc vs Zbkb. |
| EEW range | On Zve32x the bit ops cover EEW 8/16/32; Zve64x adds EEW 64 (and is required for Zvbc’s 64-bit carry-less products). |
Hardware Designer Notes
This page is the design rationale for the split rather than new silicon. The takeaway for an architect: the bit ops are a general SIMD win worth having regardless of crypto plans; the clmul multiplier is the one item to justify by workload. The Sail model closes the chapter.
Minimal Linux-boot hart MUST
- Implement the Zvbb bit ops as per-lane wiring/reduction (reverses, counts) and barrel rotators — cheap, general
- Gate Zvbc’s carry-less multiplier as a separate area decision; require Zve64x for its 64-bit products
- If claiming Zvkt, make ALL these instructions data-independent in latency
MAY simplify / trap-and-emulate
- Ship Zvbb for its general SIMD value independent of any crypto extension
- Share the carry-less multiplier with the dedicated vghsh datapath
Check yourself — bitmanip & clmul specification
1.§33.5 groups the vector bitmanip and carry-less multiply instructions separately from the cryptographic ones. Why the distinction?
2.Why does the carry-less multiply get its own extension (Zvbc) rather than folding into Zvbb?