Zc* refactors the C extension into named subsets and adds new 16-bit-only extensions aimed at embedded cores. For a Linux-class RV64GC design the practical takeaways are the taxonomy zc* taxonomy Zca = C minus FP loads/stores; Zcf (RV32+F) / Zcd (D) = the compressed FP load/store subsets; C = Zca[+Zcf][+Zcd]. Zcb = simple 16-bit extras (gated on M/Zbb); Zcmp = push/pop; Zcmt = table jumps; Zce = the microcontroller bundle. Zcmp/Zcmt reuse c.fsdsp encodings and are INCOMPATIBLE with Zcd. defined in ch. I·29 — open in glossary itself — because ISA strings, MISA.C, and one genuine encoding conflict all hang off it.
| Contains | Depends on / conflicts | |
|---|---|---|
| Zca | All of C except the FP loads/stores | — |
| Zcf (RV32 only) | c.flw[sp], c.fsw[sp] | Zca + F; does not exist on RV64 |
| Zcd | c.fld[sp], c.fsd[sp] | Zca + D |
| Zcb | c.lbu/lhu/lh, c.sb/sh, c.zext/sext.b/h, c.zext.w, c.not, c.mul | Zca; per-instruction gates |
| Zcmp | cm.push/pop/popret[z], cm.mva01s/mvsa01 | Zca; REUSES c.fsdsp space → incompatible with Zcd |
| Zcmt | cm.jt/cm.jalt + the jvt CSR | Zca + Zicsr; same c.fsdsp reuse → same Zcd conflict |
| Zce | The microcontroller bundle: Zca+Zcb+Zcmp+Zcmt (+Zcf on RV32F) | RV32IMC → RV32IM_Zce in ISA strings |
Composition rules: C = Zca, plus Zcf if F (RV32), plus Zcd if D. Hence C always implies Zca; C+F implies Zcf (RV32); C+D implies Zcd.
MISA.C is set exactly when the implemented combination reconstitutes C: Zca alone without F; Zca+Zcf with F-but-not-D (RV32); Zca+Zcf+Zcd with D (RV32); Zca+Zcd with D (RV64) — and those configurations exclude Zcmp/Zcmt.
New instruction formats (29.11)
The additions bring eight new 16-bit formats, all register-restricted to
the prime set: CLB/CSB (byte load/store, 2-bit uimm), CLH/CSH
(halfword, 1-bit uimm + funct1), CU (unary ops — rd′ = rs1′),
CMMV (two 3-bit s-register specifiers), CMJT (8-bit table index),
CMPP (register-list urlist + stack-adjust spimm). c.mul reuses
plain CA.
Hardware Designer Notes
The next pages cover the three sub-extensions in depth — Zcb’s simple expansions, Zcmp’s microcoded push/pop (the first RVC instructions that are NOT 1:1 expansions), and Zcmt’s table jumps with their second implicit instruction fetch. Even if your core skips them, their fault models are worth reading: they preview Vol II’s xEPC/xTVAL attribution rules in miniature.
Minimal Linux-boot hart MUST
- On a D-class core, keep the c.fsdsp/c.fldsp encodings as FP loads/stores — never decode cm.* there
- Set MISA.C only for exact C-equivalent configurations
- Gate each Zcb instruction on its parent extension if you adopt Zcb
MAY simplify / trap-and-emulate
- Adopt Zcb on an application core — 11 pure-decoder expansions, no state, no conflicts
- Ignore Zcmp/Zcmt entirely for Linux-class designs — they are embedded-profile tools
Check yourself — Zc* taxonomy
1.Your RV64GC application-class core wants to add Zcmp for smaller kernels. What's the problem?
2.When is MISA.C legitimately set in terms of Zc* extensions?
3.c.mul is a Zcb instruction. When must your Zcb core implement it?