I thought this was interesting, although of course I agree with many commenters' take that the lack of reference to the "old-school" ARM where everything was conditional is odd.
I got curious about how RISC-V handles this, but only curious enough to find [1] and not dig any further. That answer is from a year ago, so perhaps there have been changes.
"cmov" and several more interesting instructions in the draft RISC-V Bitmanip proposal were dropped before it reached 1.0 though.
There is a new proposal: Zicond, but it is quite crude, with two instructions. The "czero.eqz" instruction does:
rd = (rs2 == 0) ? 0 : rs1;
And the other "czero.nez" tests for "rs2 != 0". Both are supposed to be result in an operand for another instruction, where a zero operand makes it a nop: for conditional add,sub,xor, etc.
Conditional move, however, takes three instructions: two results where either is zero which get or'ed together.
Otherwise, the intention was that bigger RISC-V cores would detect a conditional branch over a single instruction in the decoder and perform macro-op fusion into a conditional instruction.
> Otherwise, the intention was that bigger RISC-V cores would detect a conditional branch over a single instruction in the decoder and perform macro-op fusion into a conditional instruction.
This seems like an overhead compared to actually having the instruction available. Could anyone say how material an overhead this is?
As far as I know, this is already hardware that implements this. [0]
> […] It is because of a special feature of the U74 that when it sees a short forward branch over exactly one ALU instruction it pairs the two instructions together in the A and B pipelines and instead of predicting whether the branch in the A pipe is taken or not it uses the result of the comparison to predicate the instruction in the B pipe.
> It turns it into a NOP at the last moment, or doesn't write the result back to the destination register or something like that.
Also note that the compressed relative branch instructions only use 16 bytes to encode.
It's obviously possible and people have done far more complicated things. It's all a question of much much you're willing to spend on the front end in terms of transistors and engineer-hours.
I got curious about how RISC-V handles this, but only curious enough to find [1] and not dig any further. That answer is from a year ago, so perhaps there have been changes.
[1]: https://stackoverflow.com/a/72341794/28169