4 ms·

yes and no - there's a few issues here: 1 - architectural - RISCV has a nice clean ISA, it's adding instructions quickly, CMOV is contentious issue there - I'

yes and no - there's a few issues here: 1 - architectural - RISCV has a nice clean ISA, it's adding instructions quickly, CMOV is contentious issue there - I'm not an expert on the history so I'll let others relitigate it - it's easy to add new instructions to a RISCV machine, unlike Intel/ARM it's even encouraged - however adding a new instruction to ALL machines is more difficult and may take many years. But unlike Intel/ARM there IS a process to adopt new instructions that doesn't involve just springing them on your customers 2 - remember RISCV is a no-condition code architecture - that would make CMOV require 3 register file ports (the only such instruction that also requires an adder [for the compare]) - register file ports are extremely expensive, especially for just 1 instruction 3 - micro-architectural - on simple pipes CMOV is pretty simple (you just inhibit register write, plus do something special with register bypass) I'd have to think very hard about how to do it on something like VRoom! with out of order, speculative, register renaming - I can see a naive way to do it, but ideally there should be a way to nullify such an instruction early in the pipe which would mean some sort of renaming-on-the-fly hack

titzer 5y ago
Note I was talking about a conditionall call instruction, which is very useful for, e.g. safety checks.
- Taniwha 5y ago
  conditional CALL is MUCH harder to implement well - it's because the call part essentially happens up at the PC/BTC end of the CPU while at the execution stage what you're doing is writing the saved PC to the LR/etc and the register compare (or accessing a condition code that may not have been calculated yet). In many ways I guess it's a bit like a conditional branch that needs a write port - in RISCV, without condition codes, your conditional call relative branch distance will be smaller because the instruction encoding will need to encode 2-3 registers
- dzaima 5y ago
  I imagine something like that might be viable in the to-be-designed RISC-V J extension, as safety checks (mostly in JITs) would be close to the only thing benefiting from this. Though, maybe instead of a conditional call, a conditional signal could do, which'd clearly give no expectation of performance if it's hit, simplifying the hardware effort required.
  - Taniwha 5y ago
    Yeah, I can imagine that being particularly easy to implement in VRoom! exceptions are handled synchronously at the end of the pipe (with everything before them already committed, and everything after flushed). Instructions that can convert to exceptions (like loads and store taking TLB misses) essentially hit two different functional units - a conditional exception would be tested in a branch/ALU unit and then transition into an effective a no-op or transition into an d exception and synchronise the pipe when they hit the commit stage
skavi 5y ago
How do you feel about short forward optimizations? If I understand it correctly, BOOMv3 can convert instructions under a short forward branch shadow to be predicated.

titzer 5y ago

Note I was talking about a conditionall call instruction, which is very useful for, e.g. safety checks.

Taniwha 5y ago
conditional CALL is MUCH harder to implement well - it's because the call part essentially happens up at the PC/BTC end of the CPU while at the execution stage what you're doing is writing the saved PC to the LR/etc and the register compare (or accessing a condition code that may not have been calculated yet). In many ways I guess it's a bit like a conditional branch that needs a write port - in RISCV, without condition codes, your conditional call relative branch distance will be smaller because the instruction encoding will need to encode 2-3 registers
dzaima 5y ago
I imagine something like that might be viable in the to-be-designed RISC-V J extension, as safety checks (mostly in JITs) would be close to the only thing benefiting from this. Though, maybe instead of a conditional call, a conditional signal could do, which'd clearly give no expectation of performance if it's hit, simplifying the hardware effort required.
- Taniwha 5y ago
  Yeah, I can imagine that being particularly easy to implement in VRoom! exceptions are handled synchronously at the end of the pipe (with everything before them already committed, and everything after flushed). Instructions that can convert to exceptions (like loads and store taking TLB misses) essentially hit two different functional units - a conditional exception would be tested in a branch/ALU unit and then transition into an effective a no-op or transition into an d exception and synchronise the pipe when they hit the commit stage

skavi 5y ago

How do you feel about short forward optimizations? If I understand it correctly, BOOMv3 can convert instructions under a short forward branch shadow to be predicated.