3 ms·

> Yet, it does not push macro-op fusion in implementations Yes it does. It pushes it as an alternative to adding instructions to the ISA. It says we don’t need

> Yet, it does not push macro-op fusion in implementations Yes it does. It pushes it as an alternative to adding instructions to the ISA. It says we don’t need these extra instructions because architects can use macro-op fusion to remove the penalty associated with having two instructions rather than one.

snvzz 3y ago
>It says we don’t need these extra instructions because architects can use macro-op fusion to remove the penalty associated with having two instructions rather than one. They are correct in saying that. x86 didn't have the chance to do so, because back when it was designed, macro-ops were not considered. Yet whether to fuse or not is still up to microarchitecture architects. RISC-V doesn't push it. Only creates the opportunity where sensible, while increasing code density which benefits everyone.
- 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)
- klelatti 3y ago
  Your definition of ‘push’ here is make compulsory - which doesn’t make sense in the context anyway. I’ll leave others to judge if the quoted paper pushes it and move on.
  - snvzz 3y ago
    >Your definition of ‘push’ here is make compulsory Macro-op fusion is entirely optional, leveraged by few hardware implementations; Fusion is useful mostly (i.e. exceptions exist) only on mid-range cores. High end cores prefer to split everything up (unnecessary on RISC-V), whereas low end cores prefer simpler hardware. Net win in code density weights more in hardware than instruction count, which remains excellent in RISC-V even when the studied microarchitecture does not implement fusion.

snvzz 3y ago

>It says we don’t need these extra instructions because architects can use macro-op fusion to remove the penalty associated with having two instructions rather than one. They are correct in saying that. x86 didn't have the chance to do so, because back when it was designed, macro-ops were not considered. Yet whether to fuse or not is still up to microarchitecture architects. RISC-V doesn't push it. Only creates the opportunity where sensible, while increasing code density which benefits everyone.

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)
klelatti 3y ago
Your definition of ‘push’ here is make compulsory - which doesn’t make sense in the context anyway. I’ll leave others to judge if the quoted paper pushes it and move on.
- snvzz 3y ago
  >Your definition of ‘push’ here is make compulsory Macro-op fusion is entirely optional, leveraged by few hardware implementations; Fusion is useful mostly (i.e. exceptions exist) only on mid-range cores. High end cores prefer to split everything up (unnecessary on RISC-V), whereas low end cores prefer simpler hardware. Net win in code density weights more in hardware than instruction count, which remains excellent in RISC-V even when the studied microarchitecture does not implement fusion.