4 ms·

I would like to suggest that the classical taxonomy of RISC/CISC dichotomy is basically non-existent nowadays -- namely because both sides have influenced each

by stevefan1999 3y ago

I would like to suggest that the classical taxonomy of RISC/CISC dichotomy is basically non-existent nowadays -- namely because both sides have influenced each other. It is well known that CISC has taken a lot of inspirations from RISC designs (such as having a lot more registers in x64), and RISC designs also taken some inspirations from CISC (such as having SIMD/vectorization units). In other words, the line between RISC and CISC has been very fine lately. Also, at the end of the day, they all turned into μops. If I remember Jim Keller correctly, ARM and x86, they are basically the same in the back nowadays, its just the frontend and their decoding units are different. And that's why he strongly suggested AMD to also adapt Zen design with ARM ISA during his tenure there, oh I think it is called K12. I think there is another blurry line between superscalar and VLIW architecture, too.

Apofis 3y ago
With all of the sanctions China is really starting to push RISC forward, challenge ARM, and they are starting to find success. That "No" has absolutely changed to a "Maybe". https://www.prnewswire.com/news-releases/global-and-china-automotive-risc-v-chip-industry-research-report-2024-customized-chips-may-become-the-future-trend-and-risc-v-will-challenge-arm-302089267.html https://www.prnewswire.com/news-releases/global-and-china-au...
fulafel 3y ago
I don't know if a reduced instruction set can "take inspiration" from a big one, it just becomes a non reduced one. Also these examples don't feel right for me: x64 has the same number of registers as CISCs traditionally did (eg m68k, z/architecture, vax). 32-bit x86 was just an exceptionally register-starved CISC. And SIMD postdates RISC vs CISC divide for a long time, both schools of architecture got SIMD around the same time. But the divide has become less relevant because originally instruction set affected chip area a lot, and there were big gains to be had by the quantitative approach of benchmarking compiled apps with different proposed instruction sets and seeing what runs fastest when transistors are spent on hot instructions vs execution engine resources. Nowadays we have more transistors than we know what to do with, and just put in lots of cores that end up sitting idle because of diminishing returns trying to speed up cores with more transistors.
abainbridge 3y ago
Yep. RISC was interesting when gate budgets for CPU pipelines were seriously limited. It was interesting because before RISC the industry had been merrily spending the gate budget increase on adding lots of use-specific instructions. The RISC people pointed out that if you removed support for all the fancy instructions you had enough gate budget for the ALU to be nicely pipelined, and then you could wind up the clock rate greatly and this was worth much more than the fancy instructions. For decades now we've had enough gate budget to have nicely pipelined designs with complex instruction sets, so that's what everyone does. RISC solves a problem that no longer exists.
- thesz 3y ago
  You are not quite right about pipelined design being faster. At least, not without substantial effort. https://en.wikipedia.org/wiki/R2000_microprocessor https://en.wikipedia.org/wiki/R2000_microprocessor "The R2000 is a 32-bit microprocessor chip set developed by MIPS Computer Systems that implemented the MIPS I instruction set architecture (ISA)..." "The R2000 was available in 8.3, 12.5 and 15 MHz grades..." https://en.wikipedia.org/wiki/I386 https://en.wikipedia.org/wiki/I386 "The Intel 386, originally released as 80386 and later renamed i386, is a 32-bit microprocessor introduced in 1985..." "Max. CPU clock rate: 12.5 MHz to 40 MHz" As you can see, 80386 was released a year earlier than R2000 and was about 1.5 times faster than MIPS implementation from the start. The critical path is, usually, in addition/subtraction, which should be complete in one cycle in both 80386 and in R2000. To pipeline addition you need a superpipelined CPU, one that has several stages for computation. Even seemingly simple computation of condition codes can make clock cycle 10% longer (SPARC vs MIPS) if your CPU is just simply pipelined. BTW, some Pentiums did computed 32-bit addition in two cycles, all in name of higher clock frequencies.
  - abainbridge 3y ago
    Interesting. An R2000 did run programs faster than a 80386, right? This was a few years before my time. From a quick google now, it looks like the R2000 was about 3x better than the 80386 at Dhrystone MIPS/MHz. I guess an accurate comparison of how the R2000 and 80386 spent they gate budget and what they got in return would involve a lot of detail. I remember my compsci professor giving us the computer architecture course in about 1997, and he dispaired at how all the clever RISC stuff in the Patterson and Hennessey seemed irrelevant when Intel could just throw money at the implementation (and fab, I guess) and produce competitive chips despite their (allegedly) inferior architecture.
CalChris 3y ago
A 20,000 gate minimal RISC-V RV32E controller CPU isn't going to use μops. In 2024, RISC-V has turned that 2015 No into an unqualified Yes even if the microarchitecture of more complex OOO RISC-V systems resemble the microarchitectures of similarly complex x86 and ARM CPUs.
- wmf 3y ago
  To the extent that RISC-V is successful it's due to openness/freeness; RISC has nothing to do with it. An open "CISC-V" community would have been just as successful (and people wouldn't gripe about instruction fusion).
- pclmulqdq 3y ago
  I have made a few of those RISC-V CPUs. The minute the "M" instruction set shows up (with division), a macro/micro-op split becomes worth it if you want to minimize gate count or maximize speed.
titzer 3y ago
I agree that the line is pretty thin, but would draw it as: fixed-width versus variable-width. I think the M? line of Apple CPUs, with extremely-wide parallel decode, has been a game changer. The performance per watt is really off the charts. That's partly due to integrated RAM and all, but mostly due to microarchitectural changes, which I believe to be a massive step function in superscalar bandwidth (wider decode, huge ROB, huge numbers of ports). It seems like the power-hungry decode stage has been tamed, and I think this is because of fixed-width instructions in arm.
jcranmer 3y ago
RISC/CISC is near the top of the list of "things emphasized in education that bear little relevance in practice". RISC isn't so much a single coherent design idea as a collection of ideas, some of which have won out (more register files), and some of which haven't (avoid instructions that take multiple clock cycles). The architectures from the days the "debate" was more relevant that have had the most success are the ones which most thoroughly blurred the lines between classical RISC and CISC--namely, Arm and x86. > I think there is another blurry line between superscalar and VLIW architecture, too. No, the line is pretty damn sharp. The core idea behind VLIW is that having hardware doing dynamic scheduling (as superscalar does) is silly and the compiler should be responsible for statically scheduling all instructions. The only blur here is that both VLIW and superscalar envision having multiple execution units that can be simultaneously scheduled with work, but who is responsible for doing that scheduling is pretty distinct.
- stevefan1999 3y ago
  Okay, I will have to review the lecture about VLIW, again: https://www.youtube.com/watch?v=nHHsYp7ZkHQ https://www.youtube.com/watch?v=nHHsYp7ZkHQ
gumby 3y ago
> RISC designs also taken some inspirations from CISC (such as having SIMD/vectorization units) I think that one went the other way: for example the PlayStation 2 used a MIPS chip with 256-bit SIMD instructions (the TMPR 5900) as well as a dedicated GPU (the so-called “emotion engine”)
simne 3y ago
> classical taxonomy of RISC/CISC dichotomy is basically non-existent nowadays After digest information about IBM 360, I decided, we lost CISCs. One of most important feature of 360 was customizable microcode, which you could load on system boot and got effectively different hardware (like with FPGA emulators of Amiga's). It was widely used to emulate old hardware, like IBM 1401 or IBM 7xxx series. But I have not seen this feature in 390 documentation, so looks like their 360 emulation become just software (and with achievements of semiconductors in 1990s it looks like adequate, to switch to software emulation). I must admit, ARM marketed feature of customized microcode, to add new instructions (they have standardized place in instruction set, named "custom coprocessor instructions", so if you have enough money, you could make special ARM with your additional instructions), but it is nothing if compare to 360.
- simne 3y ago
  Did you know for what purposes (targets) made mini-computers and why they was limited? When computers first appeared, they was big, just because technology limitations made small machines very expensive to use, so scale used to make computations cheaper. In early 1970s, technology advanced to stage, where become possible to make simplified versions of big computers for some limited tasks, still too expensive for wide use. Simple illustration, IBM-3033 mainframe with 16MBytes RAM could serve 17500 3270 terminals, and PDP of same time could about few tens (may be 50, I don't know exactly), so mainframes even when was very expensive, but given good cost per workplace. Known example, PDP used to control one of scientific nuclear reactor. PDP chosen, not because it have best mips/price ratio, but because it was cheapest adequate machine for this task, so is affordable for limited budget. Very long time, mini machines stay in niche of limited machines, used to avoid much more expensive full-scale mainframes. They used to control industrial automation (CNC), chemical factories and other small things. Once appeared microcomputers (CPU on one chip), first known on wide market in 1977, they begin eat mini's space from bottom, when mainframes continue to become more cost effective (more terminals with appearance of cheap modems, etc) and eat mini's space from top. And in 1990s, when appeared affordable 32-bit microprocessors and became affordable Megabytes of RAM, mini's disappear, because their place was captured by micro's. To be honest, I just don't know anything we could not name microcomputer now, as even IBM Z mainframes are now have single-chip processor and largest supercomputers are practically clouds of SOCs (NUMA architecture). And I must admit, I still see PDP's (or VAX's) on enterprises, where they still control old machines from 1990s (they are very reliable even when limited from modern view, but still work). As I remember, last symmetrical multiprocessor supercomputer was Cray Y-MP, later machines become ccNUMA or just NUMA or even cloud. https://en.wikipedia.org/wiki/LINPACK https://en.wikipedia.org/wiki/LINPACK Unix was simplified version of Multics, system considered to run on mainframes (BTW even exists officially certified Posix Unix for mainframes). You could try mainframes software yourself, it is very affordable now with emulator (sure, be careful about license): https://en.wikipedia.org/wiki/Hercules_(emulator) https://en.wikipedia.org/wiki/Hercules_(emulator) And you will see yourself, how many things borrowed by modern OS's from mainframes. This is nature, people choose simpler, cheaper thing (yes, I don't like x86, my love is 68k).

Apofis 3y ago

With all of the sanctions China is really starting to push RISC forward, challenge ARM, and they are starting to find success. That "No" has absolutely changed to a "Maybe". https://www.prnewswire.com/news-releases/global-and-china-automotive-risc-v-chip-industry-research-report-2024-customized-chips-may-become-the-future-trend-and-risc-v-will-challenge-arm-302089267.html https://www.prnewswire.com/news-releases/global-and-china-au...

fulafel 3y ago

I don't know if a reduced instruction set can "take inspiration" from a big one, it just becomes a non reduced one. Also these examples don't feel right for me: x64 has the same number of registers as CISCs traditionally did (eg m68k, z/architecture, vax). 32-bit x86 was just an exceptionally register-starved CISC. And SIMD postdates RISC vs CISC divide for a long time, both schools of architecture got SIMD around the same time. But the divide has become less relevant because originally instruction set affected chip area a lot, and there were big gains to be had by the quantitative approach of benchmarking compiled apps with different proposed instruction sets and seeing what runs fastest when transistors are spent on hot instructions vs execution engine resources. Nowadays we have more transistors than we know what to do with, and just put in lots of cores that end up sitting idle because of diminishing returns trying to speed up cores with more transistors.

abainbridge 3y ago

Yep. RISC was interesting when gate budgets for CPU pipelines were seriously limited. It was interesting because before RISC the industry had been merrily spending the gate budget increase on adding lots of use-specific instructions. The RISC people pointed out that if you removed support for all the fancy instructions you had enough gate budget for the ALU to be nicely pipelined, and then you could wind up the clock rate greatly and this was worth much more than the fancy instructions. For decades now we've had enough gate budget to have nicely pipelined designs with complex instruction sets, so that's what everyone does. RISC solves a problem that no longer exists.

thesz 3y ago
You are not quite right about pipelined design being faster. At least, not without substantial effort. https://en.wikipedia.org/wiki/R2000_microprocessor https://en.wikipedia.org/wiki/R2000_microprocessor "The R2000 is a 32-bit microprocessor chip set developed by MIPS Computer Systems that implemented the MIPS I instruction set architecture (ISA)..." "The R2000 was available in 8.3, 12.5 and 15 MHz grades..." https://en.wikipedia.org/wiki/I386 https://en.wikipedia.org/wiki/I386 "The Intel 386, originally released as 80386 and later renamed i386, is a 32-bit microprocessor introduced in 1985..." "Max. CPU clock rate: 12.5 MHz to 40 MHz" As you can see, 80386 was released a year earlier than R2000 and was about 1.5 times faster than MIPS implementation from the start. The critical path is, usually, in addition/subtraction, which should be complete in one cycle in both 80386 and in R2000. To pipeline addition you need a superpipelined CPU, one that has several stages for computation. Even seemingly simple computation of condition codes can make clock cycle 10% longer (SPARC vs MIPS) if your CPU is just simply pipelined. BTW, some Pentiums did computed 32-bit addition in two cycles, all in name of higher clock frequencies.
- abainbridge 3y ago
  Interesting. An R2000 did run programs faster than a 80386, right? This was a few years before my time. From a quick google now, it looks like the R2000 was about 3x better than the 80386 at Dhrystone MIPS/MHz. I guess an accurate comparison of how the R2000 and 80386 spent they gate budget and what they got in return would involve a lot of detail. I remember my compsci professor giving us the computer architecture course in about 1997, and he dispaired at how all the clever RISC stuff in the Patterson and Hennessey seemed irrelevant when Intel could just throw money at the implementation (and fab, I guess) and produce competitive chips despite their (allegedly) inferior architecture.

CalChris 3y ago

A 20,000 gate minimal RISC-V RV32E controller CPU isn't going to use μops. In 2024, RISC-V has turned that 2015 No into an unqualified Yes even if the microarchitecture of more complex OOO RISC-V systems resemble the microarchitectures of similarly complex x86 and ARM CPUs.

wmf 3y ago
To the extent that RISC-V is successful it's due to openness/freeness; RISC has nothing to do with it. An open "CISC-V" community would have been just as successful (and people wouldn't gripe about instruction fusion).
pclmulqdq 3y ago
I have made a few of those RISC-V CPUs. The minute the "M" instruction set shows up (with division), a macro/micro-op split becomes worth it if you want to minimize gate count or maximize speed.

titzer 3y ago

I agree that the line is pretty thin, but would draw it as: fixed-width versus variable-width. I think the M? line of Apple CPUs, with extremely-wide parallel decode, has been a game changer. The performance per watt is really off the charts. That's partly due to integrated RAM and all, but mostly due to microarchitectural changes, which I believe to be a massive step function in superscalar bandwidth (wider decode, huge ROB, huge numbers of ports). It seems like the power-hungry decode stage has been tamed, and I think this is because of fixed-width instructions in arm.

jcranmer 3y ago

RISC/CISC is near the top of the list of "things emphasized in education that bear little relevance in practice". RISC isn't so much a single coherent design idea as a collection of ideas, some of which have won out (more register files), and some of which haven't (avoid instructions that take multiple clock cycles). The architectures from the days the "debate" was more relevant that have had the most success are the ones which most thoroughly blurred the lines between classical RISC and CISC--namely, Arm and x86. > I think there is another blurry line between superscalar and VLIW architecture, too. No, the line is pretty damn sharp. The core idea behind VLIW is that having hardware doing dynamic scheduling (as superscalar does) is silly and the compiler should be responsible for statically scheduling all instructions. The only blur here is that both VLIW and superscalar envision having multiple execution units that can be simultaneously scheduled with work, but who is responsible for doing that scheduling is pretty distinct.

stevefan1999 3y ago
Okay, I will have to review the lecture about VLIW, again: https://www.youtube.com/watch?v=nHHsYp7ZkHQ https://www.youtube.com/watch?v=nHHsYp7ZkHQ

gumby 3y ago

> RISC designs also taken some inspirations from CISC (such as having SIMD/vectorization units) I think that one went the other way: for example the PlayStation 2 used a MIPS chip with 256-bit SIMD instructions (the TMPR 5900) as well as a dedicated GPU (the so-called “emotion engine”)

simne 3y ago

> classical taxonomy of RISC/CISC dichotomy is basically non-existent nowadays After digest information about IBM 360, I decided, we lost CISCs. One of most important feature of 360 was customizable microcode, which you could load on system boot and got effectively different hardware (like with FPGA emulators of Amiga's). It was widely used to emulate old hardware, like IBM 1401 or IBM 7xxx series. But I have not seen this feature in 390 documentation, so looks like their 360 emulation become just software (and with achievements of semiconductors in 1990s it looks like adequate, to switch to software emulation). I must admit, ARM marketed feature of customized microcode, to add new instructions (they have standardized place in instruction set, named "custom coprocessor instructions", so if you have enough money, you could make special ARM with your additional instructions), but it is nothing if compare to 360.

simne 3y ago
Did you know for what purposes (targets) made mini-computers and why they was limited? When computers first appeared, they was big, just because technology limitations made small machines very expensive to use, so scale used to make computations cheaper. In early 1970s, technology advanced to stage, where become possible to make simplified versions of big computers for some limited tasks, still too expensive for wide use. Simple illustration, IBM-3033 mainframe with 16MBytes RAM could serve 17500 3270 terminals, and PDP of same time could about few tens (may be 50, I don't know exactly), so mainframes even when was very expensive, but given good cost per workplace. Known example, PDP used to control one of scientific nuclear reactor. PDP chosen, not because it have best mips/price ratio, but because it was cheapest adequate machine for this task, so is affordable for limited budget. Very long time, mini machines stay in niche of limited machines, used to avoid much more expensive full-scale mainframes. They used to control industrial automation (CNC), chemical factories and other small things. Once appeared microcomputers (CPU on one chip), first known on wide market in 1977, they begin eat mini's space from bottom, when mainframes continue to become more cost effective (more terminals with appearance of cheap modems, etc) and eat mini's space from top. And in 1990s, when appeared affordable 32-bit microprocessors and became affordable Megabytes of RAM, mini's disappear, because their place was captured by micro's. To be honest, I just don't know anything we could not name microcomputer now, as even IBM Z mainframes are now have single-chip processor and largest supercomputers are practically clouds of SOCs (NUMA architecture). And I must admit, I still see PDP's (or VAX's) on enterprises, where they still control old machines from 1990s (they are very reliable even when limited from modern view, but still work). As I remember, last symmetrical multiprocessor supercomputer was Cray Y-MP, later machines become ccNUMA or just NUMA or even cloud. https://en.wikipedia.org/wiki/LINPACK https://en.wikipedia.org/wiki/LINPACK Unix was simplified version of Multics, system considered to run on mainframes (BTW even exists officially certified Posix Unix for mainframes). You could try mainframes software yourself, it is very affordable now with emulator (sure, be careful about license): https://en.wikipedia.org/wiki/Hercules_(emulator) https://en.wikipedia.org/wiki/Hercules_(emulator) And you will see yourself, how many things borrowed by modern OS's from mainframes. This is nature, people choose simpler, cheaper thing (yes, I don't like x86, my love is 68k).