4 ms·

Compressed Instructions and Macro-Operation Fusion It's strange to put these two together as RISC-V's killer feature. First, they are not new; they go back mor

Compressed Instructions and Macro-Operation Fusion It's strange to put these two together as RISC-V's killer feature. First, they are not new; they go back more than a decade. But more to the point, they are at odds. Instruction compression says that DRAM+cache are a scarce resource. Macro-op fusion says don't worry about those big instructions, we'll combine them after decode. Which is it? BTW, micro-op fusion is not free. It has to search the instruction stream for possible matches.

pjc50 6y ago
Obviously the plan is to take a short string of bytes, expand it to a longer one, and then identify a single instruction that those bytes map to. This is much cleverer than just mapping the original string of bytes directly to an instruction. /s
socialdemocrat 6y ago
With compression you avoid the cost of having multiple instructions to fuse. I don't see what that isn't a good combination. With two instructions compressed into one and then fused into one micro-op you get both less pressure on cache while still getting high throughput in the micro-op execution pipeline. The "killer feature" here is about designing the ISA around the fact that one knows macro-op fusion and compression exists. E.g. x86 ISA was designed without any thought to the possible existence of macro-o fusion. ARM seems to also have mostly ignored the existence of this in high end processors when designing their ISA. Innovation is really just about using existing stuff in clever new ways. Btw Macro-op fusion and micro-op fusion are not the same thing.
- CalChris 6y ago
  Doh. Yes, I fat fingered micro-op for macro-op. With compression you avoid the cost of having multiple instructions to fuse. I don't understand this. RVC is only a 16b 'abbreviation' for a subset of RISCV instructions. It's ultimately the same instruction. Also, RVC is an extension; it isn't base and Andrew Waterman's thesis [1] doesn't even mention macro-op fusion. FWIW, the A72 uses macro-op fusion [2]. Neither architecture ruled it out, but then neither architecture was anticipating it. It's just a microarchitectural optimization. No, the x86 (1978) certainly wasn't designed with macro-op fusion in mind. Instead, macro-op fusion (2000) was developed by Intel to improve x86 performance [3]. [1] https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.pdf https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p... [2] https://techreport.com/review/28189/inside-arms-cortex-a72-microarchitecture/ https://techreport.com/review/28189/inside-arms-cortex-a72-m... [3] https://patents.google.com/patent/US6675376 https://patents.google.com/patent/US6675376
  - socialdemocrat 6y ago
    If I got two 16-bit instructions packed into a 32-bit word which then get fused, what I have achieved is equivalent to adding complex instruction to the ISA without really adding it. It is like being able to make arbitrary CISC instruction by combining various RVC instructions. How is that not a good thing? It is like being able to add tons of instructions without consuming any extra ISA encoding space. I don’t see why compressed instructions and macro fusions need to be part of the base instructions. These are just micro-architecture optimizations available to you if you want higher performance. For a cheap small microcontroller you don’t want it.
    - jabl 6y ago
      AFAICS the argument is that the alternative approach of adding the most common instruction combinations to the base ISA (like base+index<<shift addressing mode) could have largely avoided the need for the C extension as well as macro-op fusion. This would have simplified the implementation of almost all cores, the exception being the smallest possible microcontroller.
      - socialdemocrat 6y ago
        But adding compression just costs 400 gates, how on earth is that an issue, even on a small controller? The C extensions saves a lot more memory than these more complex instructions. So even if you don't add macro fusion, you are still getting advantages from fewer cache misses or less money spent on cache. You seem to talk theory, when in practice we know the BOOM RISC-V CPU outperforms a ARM-32 Cortex-A9, while requiring half the silicon area. The RISC-V is 0.27 mm2 while the ARM is 0.53 mm2 using same technology. And what you are missing from the overall picture is that a key requirement for RISC-V is that it is useable in academia and for teaching. It is supposed to be easy for students to learn as well as to implement simple RISC-V CPU cores. All of that is quickly out the window if you go down the ARM road. That RISC-V pulls off all these things: higher performance, smaller die, simpler implementation and easier to teach validates IMHO their choices. I don't see how your argument has any legs to stand on.

pjc50 6y ago

Obviously the plan is to take a short string of bytes, expand it to a longer one, and then identify a single instruction that those bytes map to. This is much cleverer than just mapping the original string of bytes directly to an instruction. /s

socialdemocrat 6y ago

With compression you avoid the cost of having multiple instructions to fuse. I don't see what that isn't a good combination. With two instructions compressed into one and then fused into one micro-op you get both less pressure on cache while still getting high throughput in the micro-op execution pipeline. The "killer feature" here is about designing the ISA around the fact that one knows macro-op fusion and compression exists. E.g. x86 ISA was designed without any thought to the possible existence of macro-o fusion. ARM seems to also have mostly ignored the existence of this in high end processors when designing their ISA. Innovation is really just about using existing stuff in clever new ways. Btw Macro-op fusion and micro-op fusion are not the same thing.

CalChris 6y ago
Doh. Yes, I fat fingered micro-op for macro-op. With compression you avoid the cost of having multiple instructions to fuse. I don't understand this. RVC is only a 16b 'abbreviation' for a subset of RISCV instructions. It's ultimately the same instruction. Also, RVC is an extension; it isn't base and Andrew Waterman's thesis [1] doesn't even mention macro-op fusion. FWIW, the A72 uses macro-op fusion [2]. Neither architecture ruled it out, but then neither architecture was anticipating it. It's just a microarchitectural optimization. No, the x86 (1978) certainly wasn't designed with macro-op fusion in mind. Instead, macro-op fusion (2000) was developed by Intel to improve x86 performance [3]. [1] https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.pdf https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p... [2] https://techreport.com/review/28189/inside-arms-cortex-a72-microarchitecture/ https://techreport.com/review/28189/inside-arms-cortex-a72-m... [3] https://patents.google.com/patent/US6675376 https://patents.google.com/patent/US6675376
- socialdemocrat 6y ago
  If I got two 16-bit instructions packed into a 32-bit word which then get fused, what I have achieved is equivalent to adding complex instruction to the ISA without really adding it. It is like being able to make arbitrary CISC instruction by combining various RVC instructions. How is that not a good thing? It is like being able to add tons of instructions without consuming any extra ISA encoding space. I don’t see why compressed instructions and macro fusions need to be part of the base instructions. These are just micro-architecture optimizations available to you if you want higher performance. For a cheap small microcontroller you don’t want it.
  - jabl 6y ago
    AFAICS the argument is that the alternative approach of adding the most common instruction combinations to the base ISA (like base+index<<shift addressing mode) could have largely avoided the need for the C extension as well as macro-op fusion. This would have simplified the implementation of almost all cores, the exception being the smallest possible microcontroller.
    - socialdemocrat 6y ago
      But adding compression just costs 400 gates, how on earth is that an issue, even on a small controller? The C extensions saves a lot more memory than these more complex instructions. So even if you don't add macro fusion, you are still getting advantages from fewer cache misses or less money spent on cache. You seem to talk theory, when in practice we know the BOOM RISC-V CPU outperforms a ARM-32 Cortex-A9, while requiring half the silicon area. The RISC-V is 0.27 mm2 while the ARM is 0.53 mm2 using same technology. And what you are missing from the overall picture is that a key requirement for RISC-V is that it is useable in academia and for teaching. It is supposed to be easy for students to learn as well as to implement simple RISC-V CPU cores. All of that is quickly out the window if you go down the ARM road. That RISC-V pulls off all these things: higher performance, smaller die, simpler implementation and easier to teach validates IMHO their choices. I don't see how your argument has any legs to stand on.