The RISC-V code size reduction group (https://github.com/riscv/riscv-code-size-reduction) has nearly completed their work. If/when this gets rolled into the accepted RISC-V specifications, Minimax benefits in a few ways:
Better compliance: RVC-compliant half/byte writes (c.sb/c.sh) plug a conspicuous implementation gap. Without them, there's no way to emulate RV32I half or byte-wide writes without hardware support. They are currently stubbed out and unsupported in Minimax, which creates an easy footgun for compiled code. With c.sb/c.sh, these writes become just another emulated instruction.
Better code density: even if the new instructions are emulated (e.g. cm.push/cm.pop/cm.popret), they still decrease code size - and where they are emulated, performance with a single instruction is much better than performance with several.
Better performance: emulated (32-bit) instructions are 40-400x slower than native (16-bit, RVC) instructions. The new instructions are (excepting table jump, and possibly excepting multiple-register pushes/pops) inexpensive in logic and worth implementing directly.
More applications: the compressed multiply instruction (c.mul) is a fascinating opportunity to make Minimax into a tiny signal-processing engine. (Unfortunately, it'd be restricted to ~16-bit precision.) This is something it flatly can't do now, even with an emulated 32-bit multiply instruction.
The RISC-V code size reduction group (https://github.com/riscv/riscv-code-size-reduction) has nearly completed their work. If/when this gets rolled into the accepted RISC-V specifications, Minimax benefits in a few ways: