5 ms·

That’s such a strange criticism given how keen the designers of RISC-V have been to push macro-op fusion.

snvzz 3y ago
Macro-op fusion is newer than x86. RISC-V is newer than macro-op fusion, and could account for it possibly being present in implementations. I do not remember ever seeing the designers of RISC-V actually push macro-op fusion.
- klelatti 3y ago
  Seriously? You weren’t aware of this? The Renewed Case for the Reduced Instruction Set Computer: Avoiding ISA Bloat with Macro-Op Fusion for RISC-V https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-130.pdf https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-130...
  - snvzz 3y ago
    Yes, very aware. Yet, it does not push macro-op fusion in implementations. It can either be done, or not done. But RISC-V creates opportunities where it is possible and not harmful to do so, while increasing code density. >Exploiting this fact, the RV64G and RV64GC effective instruction count can be reduced by 5.4% on average by leveraging macro-op fusion. It is up to the architects behind implementations to decide when and if to take advantage of the opportunities created by RISC-V's design to do macro-op fusion.
    - klelatti 3y ago
      > 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)
  - mananaysiempre 3y ago
    Not a CPU designer by any means, but I imagine mundane RMW ops on regular registers, like the second half of LUI+ADD, are easier to handle than a flags register that is implicitly threaded through the entirety of the program. So the argument against the CMP+BEQ design could be all the other possible occurrences of BEQ the architecture is required to handle, not the one that can be fused (or not) with a preceding instruction. (Then RISC-V goes and introduces a flags register for floating-point ops...)
    - deleted 3y ago
      [deleted]
    - dzaima 3y ago
      A flags register is "threaded through the entirety of the program" just as much as all other registers. Though lui+add does have the benefit that the add should write over the lui result, whereas cmp+branch needs to both update the flags & do the branch (but x86 cores should have no problem with that, as every single add & xor & and & inc & load & etc also write to flags already). Flags for FP aren't particularly nice, but without them you just can't implement <fenv.h> which software may be expecting. (of course using a global flag for semantics isn't particularly nice either, but hey that's what's been standardized in C)
- fanf2 3y ago
  The first processor I know of that did macro-op fusion was the Inmos T9000 transputer in 1993.

Macro-op fusion is newer than x86. RISC-V is newer than macro-op fusion, and could account for it possibly being present in implementations. I do not remember ever seeing the designers of RISC-V actually push macro-op fusion.

klelatti 3y ago
Seriously? You weren’t aware of this? The Renewed Case for the Reduced Instruction Set Computer: Avoiding ISA Bloat with Macro-Op Fusion for RISC-V https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-130.pdf https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-130...
- snvzz 3y ago
  Yes, very aware. Yet, it does not push macro-op fusion in implementations. It can either be done, or not done. But RISC-V creates opportunities where it is possible and not harmful to do so, while increasing code density. >Exploiting this fact, the RV64G and RV64GC effective instruction count can be reduced by 5.4% on average by leveraging macro-op fusion. It is up to the architects behind implementations to decide when and if to take advantage of the opportunities created by RISC-V's design to do macro-op fusion.
  - klelatti 3y ago
    > 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)
- mananaysiempre 3y ago
  Not a CPU designer by any means, but I imagine mundane RMW ops on regular registers, like the second half of LUI+ADD, are easier to handle than a flags register that is implicitly threaded through the entirety of the program. So the argument against the CMP+BEQ design could be all the other possible occurrences of BEQ the architecture is required to handle, not the one that can be fused (or not) with a preceding instruction. (Then RISC-V goes and introduces a flags register for floating-point ops...)
  - deleted 3y ago
    [deleted]
  - dzaima 3y ago
    A flags register is "threaded through the entirety of the program" just as much as all other registers. Though lui+add does have the benefit that the add should write over the lui result, whereas cmp+branch needs to both update the flags & do the branch (but x86 cores should have no problem with that, as every single add & xor & and & inc & load & etc also write to flags already). Flags for FP aren't particularly nice, but without them you just can't implement <fenv.h> which software may be expecting. (of course using a global flag for semantics isn't particularly nice either, but hey that's what's been standardized in C)
fanf2 3y ago
The first processor I know of that did macro-op fusion was the Inmos T9000 transputer in 1993.