When ternary `cmov` got removed from -Zb?

[Vadím Sukhomlínov]

Hi All,

I'm looking for the justification on why ternary `cmov` was removed. It looks like it was in v0.93 (https://github.com/riscv/riscv-bitmanip/releases/download/v0.93/bitmanip-0.93.pdf), but not in 0.94.60 (https://github.com/riscv/riscv-bitmanip/releases/tag/v0.94.60).

An "initial conversion" (https://github.com/riscv/riscv-bitmanip/commit/08dea82df087bdd852711a88366849741ff126bf) conversion marking start of the 0.94.60 already don't have it - could it be lost in some broken automated process?

cmov is highly useful for the security focused implementations as it has better properties against side-channel attacks vs. proposed by -Zicond sequence:
```
czero.eqz rd, rs1, rc
czero.nez rtmp, rs2, rc
or rd, rd, rtmp

```

Regards,

Vadim

[Craig Topper]

The 0.93 spec contained 10 Zb* extensions. CMOV was part of Zbt. Only 4 of those extensions were chosen to move forward for ratification, Zba, Zbb, Zbs, and Zbc. The 0.94 spec contains only those 4 extensions that were chosen to move forward. I think the main reason CMOV wasn't pursued is because it requires reading 3 sources which may require an additional register file read port to be implemented in hardware.

-Craig

[Vadím Sukhomlínov]

Hi Craig,

Thanks for the possible explanation. Do you know if it is documented somewhere? It may then be that a new RISC-V extension focusing on the security ICs is needed to add these instructions and possibly other features useful for the side-channel and fault injection hardening. I'd put cmov and funnel shifts into that list.

Regards,

Vadim

[Vadím Sukhomlínov]

I also found a discussion about -Zicond - https://groups.google.com/u/0/a/groups.riscv.org/g/isa-dev/c/LD43tK9hTZI/m/b0r7ElaiAwAJ:

> Summary: With Zicond, we see no gain in code size and (if the hardware
> supports fused instruction) no gain in speed either. If conditional
> instructions are of interest for RISC-V we believe that a "conditional
> move" would be more useful, as it can also be used as a "conditional
> clear" when "x0" is used as the source register.

It also mentions that:

> If the ISA supports 3-input instructions but the implementation breaks them into multiple µops then that loses a lot of the point of them.

and:

> Three-input integer instructions certainly have a much bigger barrier

> to overcome for consideration for non-Zfinx systems.

> In terms of evaluation, it would be interesting to see the incremental
> benefit across a range of benchmarks in performance and code size once
> Zicond (which has much smaller cost) is included in baseline. It
> might be the gain is large enough for those building Zfinx to consider
> proposing as a extension.

> To be clear, I'm personally skeptical of there being a significant
> benefit, assuming Zicond in baseline, even for Zfinx systems, but we
> should always be open to seeing the quantitative data.

There is also some discussion in review of 0.9 bitmanip: https://groups.google.com/u/0/a/groups.riscv.org/g/isa-dev/c/0emw3Y8ZNxY/m/92GlutmbAQAJ

But still, it is not directly explaining wherever that was a reason to remove it completely instead of moving into optional extension. The issue with other alternatives is that they are either not a constant time (unless you create a very balanced branches for in-order core) and or not side-channel hardening friendly - have values like 0 or 0xfff..ff which have distinct signatures.

Regards,

Vadim

[BGB]

On 10/2/2025 3:55 PM, 'Craig Topper' via RISC-V ISA Dev wrote:
> The 0.93 spec contained 10 Zb* extensions. CMOV was part of Zbt. Only 4
> of those extensions were chosen to move forward for ratification, Zba,
> Zbb, Zbs, and Zbc. The 0.94 spec contains only those 4 extensions that
> were chosen to move forward. I think the main reason CMOV wasn't pursued
> is because it requires reading 3 sources which may require an additional
> register file read port to be implemented in hardware.
>

IMHO, categorically disallowing 3R1W encodings is overly limiting:
Indexed Store;
Integer Multiply-Accumulate;
Conditional Move/Select;
Funnel Shift;
...

Makes more sense merely to optimize for 2R1W, but then allow 3R1W
instructions to be optionally supported for implementations where doing
so is not a significant burden (eg: 2 or 3 wide in-order superscalar
machines, etc).

In these cases, 3R1W instructions may reduce effective pipeline width,
but can bring more benefit than they cost.

As I understand it, 3R1W is more of an inconvenience for OoO machines,
but these processors are far more in a position to "eat the cost" than
in the other categories.


And, for small microcontrollers, they are more in a position to simply
omit supporting them.



Though, as I can note, even within my own "feature wishlist" for
mainline RISC-V, the most useful instructions can still be done within a
2R1W configuration.

So, it is more of a "what feature has enough value-added to crack the
ice?" thing...

> -Craig
>
> On Thursday, October 2, 2025 at 1:43:13 PM UTC-7 Vadím Sukhomlínov wrote:
>
> Hi All,
>
> I'm looking for the justification on why ternary `cmov` was removed.
> It looks like it was in v0.93 (https://github.com/riscv/riscv-

> bitmanip/releases/download/v0.93/bitmanip-0.93.pdf <https://
> github.com/riscv/riscv-bitmanip/releases/download/v0.93/
> bitmanip-0.93.pdf>), but not in 0.94.60 (https://github.com/riscv/
> riscv-bitmanip/releases/tag/v0.94.60 <https://github.com/riscv/
> riscv-bitmanip/releases/tag/v0.94.60>).
>
> An "initial conversion" (https://github.com/riscv/riscv-bitmanip/
> commit/08dea82df087bdd852711a88366849741ff126bf <https://github.com/
> riscv/riscv-bitmanip/
> commit/08dea82df087bdd852711a88366849741ff126bf>) conversion marking

> start of the 0.94.60 already don't have it - could it be lost in
> some broken automated process?
>
> cmov is highly useful for the security focused implementations as it
> has better properties against side-channel attacks vs. proposed by -
> Zicond sequence:
> ```
> czero.eqz rd, rs1, rc
> czero.nez rtmp, rs2, rc
> or rd, rd, rtmp
> ```
>
> Regards,
> Vadim
>

> --
> You received this message because you are subscribed to the Google
> Groups "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to isa-dev+u...@groups.riscv.org <mailto:isa-
> dev+uns...@groups.riscv.org>.
> To view this discussion visit https://groups.google.com/a/
> groups.riscv.org/d/msgid/isa-
> dev/7eded9d5-20a1-4ba2-84dc-18bd8b66871dn%40groups.riscv.org <https://
> groups.google.com/a/groups.riscv.org/d/msgid/isa-
> dev/7eded9d5-20a1-4ba2-84dc-18bd8b66871dn%40groups.riscv.org?
> utm_medium=email&utm_source=footer>.

[Vadím Sukhomlínov]

BGB,

In my specific case it is already implemented https://ibex-core.readthedocs.io/en/latest/01_overview/compliance.html, but because it was removed from the standard later, I'm concerned with the toolchain support for it on one side and on the directions to take for the future cores.

Secure ICs are a special case of embedded/microcontroller where extra complexity required to pass certifications is justifiable, so issues with 3R1W are less of an issue. 

Regards,

Vadim

To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/1c2b2ff7-88a1-42fa-b739-6f61cd987b69%40gmail.com.

[Al Martin]

Besides being expensive in terms of register read ports, it is also expensive in terms of opcode space.

It is possible that bitmanip instructions which were not included in the ratified spec can be revisited.  For instance, some were added to extensions such as Zbkb and Zbkx, for cryptography workloads.

I think the right place to discuss this is in the Scalar Efficiency SIG.

Al Martin (@Akeana)

[Vadím Sukhomlínov]

Al, thanks for the tip - indeed looks like CMOV is in the scope for the Scalar Efficiency SIG: https://github.com/riscv-admin/riscv-scalar-efficiency/blob/main/insts/inst_table.adoc

Regards,
Vadim