4 ms·

"RISC" architectures are doing something effectively identical to uop fusion though. The real myth is the idea of a CISC/RISC dichotomy in the first place when

by ajross 3y ago

"RISC" architectures are doing something effectively identical to uop fusion though. The real myth is the idea of a CISC/RISC dichotomy in the first place when frankly that notion only ever applied to the ISA specifications and not (except for the very earliest cores) CPU designs. In point of fact beyond the instruction decode stage all modern cores look more or less identical.

jeffbee 3y ago
That's because there are only a few ISAs left standing. The ISA does have consequences for core design. This becomes apparent for ISAs that were unintentionally on the wrong side of the development of superscalar. The dead ISAs assumed in-order, single-issue, fixed-length pipelines and as soon as the state of the art shifted those ISAs became hard to implement. MIPS and SPARC are both basically incompatible with modern high-performance CPU design techniques.
- ajross 3y ago
  > MIPS and SPARC are both basically incompatible with modern high-performance CPU design techniques. I don't see how that follows at all? MIPS in fact is about as pure a "RISC" implementation as is possible to conceive[1], and it shares all its core ideas with RISC-V. You absolutely could make a deeply pipelined superscalar multi-core MIPS chip. SPARC has the hardware stack engine to worry about, but then modern CPUs have all moved to behind-the-scenes stack virtualization anyway. No, CPUs are CPUs. Instruction set architectures are a vanishingly tiny subset of the design of these things. They just don't matter. They only seem to matter to programmers like us, because it's the only part we see. [1] Branch delay slots and integer multiply instruction notwithstanding I guess.
  - jeffbee 3y ago
    The design of RISC-V starts with an entire chapter excoriating MIPS for being useless and impossible to reduce to transistors.
    - allenrb 3y ago
      Some of the same people were involved, no? They must have had a good time writing that. “Things we have learned the hard way”.
      - mumbel 3y ago
        And now MIPS, the company, makes RISC-V
      - brucehoult 3y ago
        Berkeley RISC I and RISC II had register windows, and led to SPARC. MIPS was Stanford. And, yes, they learned the hard way that register windows are a bad idea. Patterson says they did it because their compiler didn't have as good register allocation as Stanford's compiler.
  - hinkley 3y ago
    We had to touch MIPS in school. Having to deal with branch delay slots was cruel. It broke some of my classmates. We were on a cusp of needing every programmer we could get and they were torturing students. I hope those teachers lost sleep over that. Am I correct in recalling they removed branch delay slots in a later iteration of the chips?
    - IAmLiterallyAB 3y ago
      IIRC They made new branch instructions without delay slots, but the normal branch instructions still have delay slots. Had to write MIPS assembly by hand recently, incredibly counter intuitive.
ant6n 3y ago
The decode with variable width instructions is one of the bottlenecks for ipc though. Its hard to imagine, for example, a 10-way decode on x86. An internal fixed with encoding inside the instruction cache may work.
- ajross 3y ago
  > Its hard to imagine, for example, a 10-way decode on x86. Uh, why? Instructions start at byte boundaries. Say you want to decode an whole 64 byte cache line at once (probably 10-14 instructions on average). Thats... 64 parallel decode units. Seems extremely doable to me, given that "instruction decode" isn't even visible as a block on the enormous die shots anyway. Obviously there's some cost there in terms of pipeline depth, but then again Sandy Bridge showed how to do caching at the uOp level to avoid that. Again, totally doable and a long-solved problem. The real reason that Intel doesn't do 10-wide decode is that it doesn't have 10 execution units to fill (itself because typical compiler-generated code can't exploit that kind of parallelism anyway).
  - formerly_proven 3y ago
    That's a Zen 2 core: https://static.wixstatic.com/media/5017e5_bbd1e91507434d40bc1318bf71af327d~mv2.jpg https://static.wixstatic.com/media/5017e5_bbd1e91507434d40bc... Overlaid on a higher resolution die shot https://static.wixstatic.com/media/5017e5_982e0e47d7c04dd6936d28007c655c09~mv2.jpg/v1/fill/w_940,h_611,al_c,q_85,usm_0.66_1.00_0.01,enc_auto/5017e5_982e0e47d7c04dd6936d28007c655c09~mv2.jpg https://static.wixstatic.com/media/5017e5_982e0e47d7c04dd693... Here's a POWER8 floorplan: https://cdn.wccftech.com/wp-content/uploads/2013/08/IBM-Power8-Core.png https://cdn.wccftech.com/wp-content/uploads/2013/08/IBM-Powe... (The decoder is subsumed under IFU) And POWER9 https://www.nextplatform.com/wp-content/uploads/2016/08/ibm-hot-chips-power9-execution-slice.jpg https://www.nextplatform.com/wp-content/uploads/2016/08/ibm-... Didn't find any recent, reliable sources for Intel cores.
    - hinkley 3y ago
      Why does the middle of the Zen FPU look like cache lines?
gumby 3y ago
> The real myth is the idea of a CISC/RISC dichotomy in the first place The divergence was one of philosophy, and had unexpected implications. CISC was a “business as usual” evolution of the 1960s view (exception: Seymour Cray) that you should make it easy to write assembly code so have lots of addressing modes and subroutines (string ops, BCD, etc) in the instruction set. RISC was realizing that software was good enough that compilers could do the heavy lifting and without all that junk hardware designers could spend their transistor budget more usefully. That’s all well and good (I was convinced at the time, anyway) but the results have been amusing. For example some RISC experiments turn out to have painted their designs into dead ends (delay slots, visible register windows, etc) while the looseness of the CISC approach allowed more optimization to be done in the micromachine. I did not see that coming! Agree on the point that the cores themselves have found a common local maximum.
- phire 3y ago
  But there wasn't ever a divergence in philosophy. It was a straight switch. In the 70s, everyone designing an ISA was doing CISC. Then in the 80s, everyone suddenly switched to designing RISC ISAs, more or less overnight. There weren't any holdouts, nobody ever designed a new CISC ISA again. The only reason why it might seem like there was a divergence is because some CPU microarchitecture designers were allowed to design new ISAs to meet their needs, while others were stuck having to design new microarchitecture for legacy CISC ISAs which were too entrenched to replace. > For example some RISC experiments turn out to have painted their designs into dead ends Which is kind of obvious in hindsight. The RISC philosophy somewhat encouraged exposing pipeline implementation details to the ISA, which is a great idea if you can design a fresh new ISA for each new CPU microarchitecture. But those RISC ISAs became entrenched, and CPU microarchitecture found themselves having to design for what are now legacy RISC ISAs and work around implementation details that don't make sense anymore. Really the divergence was fresh ISAs vs legacy ISAs. > while the looseness of the CISC approach allowed more optimisation to be done in the micromachine. I don't think this is actually an inherent advantage of CISC. It's simply result of the shear amount of R&D that AMD, Intel, and others poured into the problem of making fast microarchitectures for x86 CPUs. If you threw the same amount of resources at any other legacy RISC ISA, you would probably get the same result.

by ajross 3y ago

jeffbee 3y ago

That's because there are only a few ISAs left standing. The ISA does have consequences for core design. This becomes apparent for ISAs that were unintentionally on the wrong side of the development of superscalar. The dead ISAs assumed in-order, single-issue, fixed-length pipelines and as soon as the state of the art shifted those ISAs became hard to implement. MIPS and SPARC are both basically incompatible with modern high-performance CPU design techniques.

ajross 3y ago
> MIPS and SPARC are both basically incompatible with modern high-performance CPU design techniques. I don't see how that follows at all? MIPS in fact is about as pure a "RISC" implementation as is possible to conceive[1], and it shares all its core ideas with RISC-V. You absolutely could make a deeply pipelined superscalar multi-core MIPS chip. SPARC has the hardware stack engine to worry about, but then modern CPUs have all moved to behind-the-scenes stack virtualization anyway. No, CPUs are CPUs. Instruction set architectures are a vanishingly tiny subset of the design of these things. They just don't matter. They only seem to matter to programmers like us, because it's the only part we see. [1] Branch delay slots and integer multiply instruction notwithstanding I guess.
- jeffbee 3y ago
  The design of RISC-V starts with an entire chapter excoriating MIPS for being useless and impossible to reduce to transistors.
  - allenrb 3y ago
    Some of the same people were involved, no? They must have had a good time writing that. “Things we have learned the hard way”.
    - mumbel 3y ago
      And now MIPS, the company, makes RISC-V
    - brucehoult 3y ago
      Berkeley RISC I and RISC II had register windows, and led to SPARC. MIPS was Stanford. And, yes, they learned the hard way that register windows are a bad idea. Patterson says they did it because their compiler didn't have as good register allocation as Stanford's compiler.
- hinkley 3y ago
  We had to touch MIPS in school. Having to deal with branch delay slots was cruel. It broke some of my classmates. We were on a cusp of needing every programmer we could get and they were torturing students. I hope those teachers lost sleep over that. Am I correct in recalling they removed branch delay slots in a later iteration of the chips?
  - IAmLiterallyAB 3y ago
    IIRC They made new branch instructions without delay slots, but the normal branch instructions still have delay slots. Had to write MIPS assembly by hand recently, incredibly counter intuitive.

ant6n 3y ago

The decode with variable width instructions is one of the bottlenecks for ipc though. Its hard to imagine, for example, a 10-way decode on x86. An internal fixed with encoding inside the instruction cache may work.

ajross 3y ago
> Its hard to imagine, for example, a 10-way decode on x86. Uh, why? Instructions start at byte boundaries. Say you want to decode an whole 64 byte cache line at once (probably 10-14 instructions on average). Thats... 64 parallel decode units. Seems extremely doable to me, given that "instruction decode" isn't even visible as a block on the enormous die shots anyway. Obviously there's some cost there in terms of pipeline depth, but then again Sandy Bridge showed how to do caching at the uOp level to avoid that. Again, totally doable and a long-solved problem. The real reason that Intel doesn't do 10-wide decode is that it doesn't have 10 execution units to fill (itself because typical compiler-generated code can't exploit that kind of parallelism anyway).
- formerly_proven 3y ago
  That's a Zen 2 core: https://static.wixstatic.com/media/5017e5_bbd1e91507434d40bc1318bf71af327d~mv2.jpg https://static.wixstatic.com/media/5017e5_bbd1e91507434d40bc... Overlaid on a higher resolution die shot https://static.wixstatic.com/media/5017e5_982e0e47d7c04dd6936d28007c655c09~mv2.jpg/v1/fill/w_940,h_611,al_c,q_85,usm_0.66_1.00_0.01,enc_auto/5017e5_982e0e47d7c04dd6936d28007c655c09~mv2.jpg https://static.wixstatic.com/media/5017e5_982e0e47d7c04dd693... Here's a POWER8 floorplan: https://cdn.wccftech.com/wp-content/uploads/2013/08/IBM-Power8-Core.png https://cdn.wccftech.com/wp-content/uploads/2013/08/IBM-Powe... (The decoder is subsumed under IFU) And POWER9 https://www.nextplatform.com/wp-content/uploads/2016/08/ibm-hot-chips-power9-execution-slice.jpg https://www.nextplatform.com/wp-content/uploads/2016/08/ibm-... Didn't find any recent, reliable sources for Intel cores.
  - hinkley 3y ago
    Why does the middle of the Zen FPU look like cache lines?

gumby 3y ago

> The real myth is the idea of a CISC/RISC dichotomy in the first place The divergence was one of philosophy, and had unexpected implications. CISC was a “business as usual” evolution of the 1960s view (exception: Seymour Cray) that you should make it easy to write assembly code so have lots of addressing modes and subroutines (string ops, BCD, etc) in the instruction set. RISC was realizing that software was good enough that compilers could do the heavy lifting and without all that junk hardware designers could spend their transistor budget more usefully. That’s all well and good (I was convinced at the time, anyway) but the results have been amusing. For example some RISC experiments turn out to have painted their designs into dead ends (delay slots, visible register windows, etc) while the looseness of the CISC approach allowed more optimization to be done in the micromachine. I did not see that coming! Agree on the point that the cores themselves have found a common local maximum.

phire 3y ago
But there wasn't ever a divergence in philosophy. It was a straight switch. In the 70s, everyone designing an ISA was doing CISC. Then in the 80s, everyone suddenly switched to designing RISC ISAs, more or less overnight. There weren't any holdouts, nobody ever designed a new CISC ISA again. The only reason why it might seem like there was a divergence is because some CPU microarchitecture designers were allowed to design new ISAs to meet their needs, while others were stuck having to design new microarchitecture for legacy CISC ISAs which were too entrenched to replace. > For example some RISC experiments turn out to have painted their designs into dead ends Which is kind of obvious in hindsight. The RISC philosophy somewhat encouraged exposing pipeline implementation details to the ISA, which is a great idea if you can design a fresh new ISA for each new CPU microarchitecture. But those RISC ISAs became entrenched, and CPU microarchitecture found themselves having to design for what are now legacy RISC ISAs and work around implementation details that don't make sense anymore. Really the divergence was fresh ISAs vs legacy ISAs. > while the looseness of the CISC approach allowed more optimisation to be done in the micromachine. I don't think this is actually an inherent advantage of CISC. It's simply result of the shear amount of R&D that AMD, Intel, and others poured into the problem of making fast microarchitectures for x86 CPUs. If you threw the same amount of resources at any other legacy RISC ISA, you would probably get the same result.