3 ms·

In the same sense that a CPU not supporting hard floats gives software the 'opportunity' to implement soft-floats. With RISC-V's current design, you can either

by tux3 3y ago

In the same sense that a CPU not supporting hard floats gives software the 'opportunity' to implement soft-floats. With RISC-V's current design, you can either not do fusion and eat a penalty, or you can do fusion. Different ISAs may have a greater or lesser need for fusion, and greater or lesser associated penalty. It seems a little obtuse to insist the ISA doesn't encourage fusion, when other ISAs would avoid a structural penalty for not having fusion, that RISC-V intentionally doesn't try to avoid at all.

snvzz 3y ago
>With RISC-V's current design, you can either not do fusion and eat a penalty, or you can do fusion. Only a small portion of existing RISC-V hardware uses fusion. This should tell you all you need to know about this mistakenly inferred "penalty" and whether RISC-V forces macro-op fusion into anybody. As per why fusion helps even when not leveraged: Not allocating encoding space to a unified opcode does, in average over a large body of code, increase code density, as shown in the paper. This means more code fits in cache, and in hardware this does weight far more than instruction count, which remains low and highly competitive even where fusion isn't leveraged.
- dzaima 3y ago
  Well, that existing RISC-V hardware is also significantly slower than modern x86/ARM, so judging the importance of fusion from them is pretty meaningless. Surprise, there's a bunch of x86 & ARM hardware without fusion (or very little of it) too! Of course, a slow core can easily afford to not have any fusion, but that's a boring question with an obvious answer. The only situation where it makes sense to ask is in the context of a fast core. I think it's pretty clear that competitively-fast RISC-V cores will need significant amounts of fusion. Anyway, in the context of the original post of cmp+branch, this doesn't even matter, as "separate cmp & branch, fused together if perf desired" and "separate add & load, fused together if perf desired" are the exact same kind of thing, so there's no reason to call one "accumulated cruft" and the other good design. (ok, there are some major problems with x86's flags, but that's primarily just because many operations needlessly update them; other than that, they're just an alternative way to achieve a thing)

by tux3 3y ago

snvzz 3y ago

>With RISC-V's current design, you can either not do fusion and eat a penalty, or you can do fusion. Only a small portion of existing RISC-V hardware uses fusion. This should tell you all you need to know about this mistakenly inferred "penalty" and whether RISC-V forces macro-op fusion into anybody. As per why fusion helps even when not leveraged: Not allocating encoding space to a unified opcode does, in average over a large body of code, increase code density, as shown in the paper. This means more code fits in cache, and in hardware this does weight far more than instruction count, which remains low and highly competitive even where fusion isn't leveraged.

dzaima 3y ago
Well, that existing RISC-V hardware is also significantly slower than modern x86/ARM, so judging the importance of fusion from them is pretty meaningless. Surprise, there's a bunch of x86 & ARM hardware without fusion (or very little of it) too! Of course, a slow core can easily afford to not have any fusion, but that's a boring question with an obvious answer. The only situation where it makes sense to ask is in the context of a fast core. I think it's pretty clear that competitively-fast RISC-V cores will need significant amounts of fusion. Anyway, in the context of the original post of cmp+branch, this doesn't even matter, as "separate cmp & branch, fused together if perf desired" and "separate add & load, fused together if perf desired" are the exact same kind of thing, so there's no reason to call one "accumulated cruft" and the other good design. (ok, there are some major problems with x86's flags, but that's primarily just because many operations needlessly update them; other than that, they're just an alternative way to achieve a thing)