5 ms·

>(fusion) Conditional branching on x86 involves using an instruction that sets flags, and then a branch that jumps (or not) depending on flags. x86 shows its a

by snvzz 3y ago

>(fusion) Conditional branching on x86 involves using an instruction that sets flags, and then a branch that jumps (or not) depending on flags. x86 shows its age and accumulated cruft here. RISC-V has test and jump in a single instruction, doing away with flags.

stavros 3y ago
Why can this not be added to x86? Is the ISA immutable now?
- pritambaral 3y ago
  It could be added with an extension, but software would continue to be compiled without it. For many, many years.
  - stavros 3y ago
    Sure, but that's fine, no? Better late than never.
    - pritambaral 3y ago
      Now that op fusion has been implemented for this idiom, the cost of a new instruction does not seem worth the benefit. The benefit would be only a tiny improvement in code size, and that's restricted to when the compiler can be absolutely certain that the target CPU is going to be modern enough to support it. So, in practice, for many, many years, this benefit would be almost never reaped. This is not a new topic in the design of ISAs and their implementations in silicon. Idiom recognition and optimization has long existed in x86, ARM, and I'm sure other old ISA implementations. RISC-V can avoid it by adding dedicated instructions because it's just getting started (relatively speaking), but even so, I'm sure there will be opportunities for idiom recognition and optimization that RISC-V implementers will take.
      - snvzz 3y ago
        >Idiom recognition and optimization On RISC-V's fusion idioms, it's not just recognition; they're designed in. Compilers are meant to try and produce them reliably, as if they were a dedicated single opcode.
  - snvzz 3y ago
    There's also the issue of code size. x86 encoding space already has a lot of clutter in it. The cost of low code density is that less code fits in cache. This cost is paid in performance, power, area or a combination of them.
- snvzz 3y ago
  >Is the ISA immutable now? x86 is, by many metrics, not a good ISA. Its value is derived from the software moat, accumulated since the late 1970s. Thus it isn't immutable. Opcodes can be added and removed. Yet breaking compatibility with old code would destroy x86's value.
  - madeofpalk 3y ago
    Can instructions be added without breaking compatibility?
    - colejohnson66 3y ago
      For x86? Yes. There are many holes in the opcode space that are regularly filled. The bespoke encoding comes from there not being (really any) holes in the beginning, and the designers trying to work around it.
    - snvzz 3y ago
      x86 opcodes can be 15 bytes long, that's how. At the expense of code density, and thus hurting PPA (Power, Performance and Area). Wildly variable opcode length does also complicate the decoder considerably, as it has to find where instructions start and end, an inherently serial operation, and yet decode enough of them to feed an n-wide pipeline.
klelatti 3y ago
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.
Scaevolus 3y ago
x86 has load and add in a single instruction, doing away with temporary register usage.
- snvzz 3y ago
  >x86 has load and add in a single instruction Sure. >doing away with temporary register usage Dubious, as that's up to implementation either way. A microarchitecture might split it into a load and an add, eliminating any instruction count reduction advantage. Whereas another microarchiture might take a separate load and add and fuse them, which would free opcode space to be used more effectively elsewhere, resulting in overall code size reduction. It's a careful balance.

by snvzz 3y ago

stavros 3y ago

Why can this not be added to x86? Is the ISA immutable now?

pritambaral 3y ago
It could be added with an extension, but software would continue to be compiled without it. For many, many years.
- stavros 3y ago
  Sure, but that's fine, no? Better late than never.
  - pritambaral 3y ago
    Now that op fusion has been implemented for this idiom, the cost of a new instruction does not seem worth the benefit. The benefit would be only a tiny improvement in code size, and that's restricted to when the compiler can be absolutely certain that the target CPU is going to be modern enough to support it. So, in practice, for many, many years, this benefit would be almost never reaped. This is not a new topic in the design of ISAs and their implementations in silicon. Idiom recognition and optimization has long existed in x86, ARM, and I'm sure other old ISA implementations. RISC-V can avoid it by adding dedicated instructions because it's just getting started (relatively speaking), but even so, I'm sure there will be opportunities for idiom recognition and optimization that RISC-V implementers will take.
    - snvzz 3y ago
      >Idiom recognition and optimization On RISC-V's fusion idioms, it's not just recognition; they're designed in. Compilers are meant to try and produce them reliably, as if they were a dedicated single opcode.
- snvzz 3y ago
  There's also the issue of code size. x86 encoding space already has a lot of clutter in it. The cost of low code density is that less code fits in cache. This cost is paid in performance, power, area or a combination of them.
snvzz 3y ago
>Is the ISA immutable now? x86 is, by many metrics, not a good ISA. Its value is derived from the software moat, accumulated since the late 1970s. Thus it isn't immutable. Opcodes can be added and removed. Yet breaking compatibility with old code would destroy x86's value.
- madeofpalk 3y ago
  Can instructions be added without breaking compatibility?
  - colejohnson66 3y ago
    For x86? Yes. There are many holes in the opcode space that are regularly filled. The bespoke encoding comes from there not being (really any) holes in the beginning, and the designers trying to work around it.
  - snvzz 3y ago
    x86 opcodes can be 15 bytes long, that's how. At the expense of code density, and thus hurting PPA (Power, Performance and Area). Wildly variable opcode length does also complicate the decoder considerably, as it has to find where instructions start and end, an inherently serial operation, and yet decode enough of them to feed an n-wide pipeline.

klelatti 3y ago

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.

Scaevolus 3y ago

x86 has load and add in a single instruction, doing away with temporary register usage.

snvzz 3y ago
>x86 has load and add in a single instruction Sure. >doing away with temporary register usage Dubious, as that's up to implementation either way. A microarchitecture might split it into a load and an add, eliminating any instruction count reduction advantage. Whereas another microarchiture might take a separate load and add and fuse them, which would free opcode space to be used more effectively elsewhere, resulting in overall code size reduction. It's a careful balance.