5 ms·
> RISC-V is designed to the momentarily fashionable idea that status flags are a big hurdle in optimizing instruction sequencing. > Modern cores rename status
by avianes 6y ago
> RISC-V is designed to the momentarily fashionable idea that status flags are a big hurdle in optimizing instruction sequencing.
> Modern cores rename status flags along with all the other registers, making them cheap.
The RISC-V is designed in particular for superscalar processors.
Renaming status registers does not make them cheap in superscalar microarchitecture.
Just as delay slots make superscalar microarchitectures even more complex.
All the microarchitectural states exposed by ISA, which allows optimization on scalar pipelined microarchitecture, make the implementation of superscalar microarchitectures more complex. Since these microarchitectural states do not represent what is actually happening in the hardware.
This explains why MIPS is so unpopular today, it is fundamentally incompatible with the superscalar microarch.
And this explains why RISC-V has chosen not to expose any microarchitectural states.
- ncmncm 6y agoI see that you missed the point. People working on current x86 and POWER say status flags are no longer considered the problem they used to be. If you are investing the real estate to be superscalar, they are a trivial complication. If you are not, then the workarounds for their lack cost.
- avianes 6y agoYou are right, I didn't answer to your point. So I'm going to complete my thought. I explain that RISC-V removes unnecessary complexity from the hardware and puts this unnecessary complexity on the software. All they did was move a problem from the hardware to the software. And that's a good thing here, because overflow checks are (almost) never in the critical path of the application, it's (almost) only used for error handling. As these checks are almost (always) out of the critical path, it doesn't matter, this can be handled in parallel. And when they are on the critical path, the cost is definitely marginal. This simplifies the hardware because it removes an implicit dependency between all instructions, leaving only the explicit register names as the dependency. It is because of this kind of factors that RISC-V cores are smaller than X86 cores, for example. Which leaves more room for optimization. But if for some applications this becomes mandatory (an hardware overflow detection or a bound checker), RISC-V can in the future also add an extension to handle it. They could, for example, add a global status flag, or a status flag per register (which would remove the implicit dependency). But for now this is not necessary. You also talk about "tortuous workarounds". But the risc-v manual talks about "single instruction" in most cases. > they are a tax on all users, but particularly on resource-constrained users who don't get instruction reordering anyway. If they have made this CPU choice it is because they don't need performance, so it's not a real issue.
- ncmncm 6y agoA small core does not demonstrate that performance does not matter. It demonstrates, exactly, constrained resources. Often performance becomes much more important because there is so little to spare.
- avianes 6y agoIf you need both performance and a small core (and not a superscalar one, because there are small superscalar cores). I will definitely not recommend you to use a RISC-V, RISC-V is not designed for that at all. You should rather turn towards some VLIW architecture (and RISC-V is not compatible with VLIW architecture) You will also gain in predictability.
- ncmncm 6y agoYet, there are no such VLIW architectures to deploy.