7 ms·

Is there a RISC dream? I think there is an efficiency "dream", there is a performance "dream", there is a cost "dream" — there are even low-complexity relative

Is there a RISC dream? I think there is an efficiency "dream", there is a performance "dream", there is a cost "dream" — there are even low-complexity relative to cost, performance and efficiency "dreams" — but a RISC dream? Who cares more about RISC than cost, performance, efficiency and simplicity?

impossiblefork 2y ago
But we define the RISC dream as a dream that efficiency, performance and low-cost could be achieved by cores with very small instruction sets?
- flanked-evergl 2y ago
  If adding more instructions negatively impacts efficiency, performance, cost and complexity, nobody would do it.
  - foldr 2y ago
    Probably true now, but in ye olde days, some instructions existed primarily to make assembly programming more convenient. Assembly programming is a real pain in the RISCiest of RISC architectures, like SPARC. Here's an example from https://www.cs.clemson.edu/course/cpsc827/material/Code%20Generation/SPARC%20Reference%20Card.pdf https://www.cs.clemson.edu/course/cpsc827/material/Code%20Ge...: • All branches (including the one caused by CALL, below) take place after execution of the following instruction. • The position immediately after a branch is the “delay slot” and the instruction found there is the “delay instruction”. • If possible, place a useful instruction in the delay slot (one which can safely be done whether or not a conditional branch is taken). • If not, place a NOP in the delay slot. • Never place any other branch instruction in a delay slot. • Do not use SET in a delay slot (only half of it is really there).
    - pjc50 2y ago
      Delay slots were such a hack. ARM never needed them.
  - patmorgan23 2y ago
    Only if decoder complexity/ efficiency is you bottleneck
- fanf2 2y ago
  Not small instruction sets, simplified instruction sets. RISC’s main trick is to reduce the number of addressing modes (eg, no memory indirect instructions) and reduce the number of memory operands per instruction to 0 or 1. Use the instruction encoding space for more registers instead. The surviving CISCs, x86 and z390 are the least CISCy CISCs. The surviving RISCs, arm and power, are the least RISCy RISCs. RISC V is a weird throwback in some aspects of its instruction set design.
  - panick21_ 2y ago
    Lets be real, its about business models. POWER was and is backed by IBM. ARM won on mobile. Does this mean POWER and ARM are better then MIPS, SPARC, PA-RISC, Am29000, i860? I don't think so.
  - Symmetry 2y ago
    More details on how RISCy or CISCy various chips are: https://userpages.umbc.edu/~vijay/mashey.on.risc.html https://userpages.umbc.edu/~vijay/mashey.on.risc.html Notably x86 is one of the less CISCy CISCs so it looks like there might be a happy medium.
Joker_vD 2y ago
There was such dream. It was about getting the mind-bogglingly simple CPU, put caches into the now empty place where all the control logic used to be, and clock it up the wazoo, and let the software deal with load/branch delays, efficiently using all 64 registers, etc. That'll beat the hell out of those silly CISC architectures at performance, and at the fraction of the design and production costs! This didn't work out, for two main reasons: first, just being able to turn clocks hella high is still not enough to get great performance: you really do want your CPU to be super-scalar, out-of-order, and with great branch predictor, if you need amazing performance. But when you do all that, the simplicity of RISC decoding stops mattering all that much, as Pentium II demonstrated when it equalled DEC Alpha on performance, while still having practically useful things like e.g. byte loads/stores. Yes, it's RISC-like instructions under the hood but that's an implementation detail, no reason to expose it to the user in the ISA, just as you don't have to expose the branch delay slots in your ISA because it's a bad idea to do so: e.g. MIPS II added 1 additional pipeline stage, and now they needed two branch/load delay slots. Whoops! So they added interlocks anyway (MIPS originally stood for "Microprocessor without Interlocked Pipelined Stages", ha-ha) and got rid of the load delays; they still left 1 branch delay slot exposed due to backwards compatibility, and the circuitry required was arguably silly. The second reason was that the software (or compilers, to be more precise) can't really deal very well with all that stuff from the first paragraph. That's what sank Itanium. That's why nobody makes CPUs with register windows any more. And static instruction scheduling in the compilers still can't beat dynamic instruction reordering.
- baq 2y ago
  Great post as it is also directly applicable to invalidate the myth that the arm instruction set somehow makes the whole cpu better than analogous x86 silicon. It might be true and responsible for like 0.1% (guesstimate) of the total advantage; it's actually all RISC under the hood and both ISAs need decoders, x86 might need a slightly bigger one which amounts to accounting noise in terms of area. c.f. https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-matter/ https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-...
- panick21_ 2y ago
  > This didn't work out ... except it did. You had literal students design chips that outperformed industry cores that took huge teams and huge investment. Acorn had a team of just a few people build a core that outperformed an i460 with likely 1/100 investment. Not to mention the even more expensive VAX chips. Can you imagine how fucking baffled the DEC engineers at the time were when their absurdly complex and absurdly expensive VAX chip were smocked by a bunch of first time chip designers? > as Pentium II demonstrated That chip came out in 1997. The original RISC chip research happened in the early 80s or even earlier. It did work, its just that x86 was bound to the PC market and Intel had the finances huge teams hammer away at the problem. x86 was able to overtake Alpha because DEC was not doing well and they couldn't invest the required amount. > no reason to expose it to the user in the ISA Except that hidden the implementation is costly. If you give 2 equal teams the same amount of money, what results in a faster chip. A team that does a simply RISC instruction set. Or a team that does a complex CISC instruction set, transforms that into an underlying simpler instruction set? Now of course for Intel, they had backward comparability so they had to do what they had to do. They were just lucky they were able to invest so much more then all the other competitors.

impossiblefork 2y ago

But we define the RISC dream as a dream that efficiency, performance and low-cost could be achieved by cores with very small instruction sets?

flanked-evergl 2y ago
If adding more instructions negatively impacts efficiency, performance, cost and complexity, nobody would do it.
- foldr 2y ago
  Probably true now, but in ye olde days, some instructions existed primarily to make assembly programming more convenient. Assembly programming is a real pain in the RISCiest of RISC architectures, like SPARC. Here's an example from https://www.cs.clemson.edu/course/cpsc827/material/Code%20Generation/SPARC%20Reference%20Card.pdf https://www.cs.clemson.edu/course/cpsc827/material/Code%20Ge...: • All branches (including the one caused by CALL, below) take place after execution of the following instruction. • The position immediately after a branch is the “delay slot” and the instruction found there is the “delay instruction”. • If possible, place a useful instruction in the delay slot (one which can safely be done whether or not a conditional branch is taken). • If not, place a NOP in the delay slot. • Never place any other branch instruction in a delay slot. • Do not use SET in a delay slot (only half of it is really there).
  - pjc50 2y ago
    Delay slots were such a hack. ARM never needed them.
- patmorgan23 2y ago
  Only if decoder complexity/ efficiency is you bottleneck
fanf2 2y ago
Not small instruction sets, simplified instruction sets. RISC’s main trick is to reduce the number of addressing modes (eg, no memory indirect instructions) and reduce the number of memory operands per instruction to 0 or 1. Use the instruction encoding space for more registers instead. The surviving CISCs, x86 and z390 are the least CISCy CISCs. The surviving RISCs, arm and power, are the least RISCy RISCs. RISC V is a weird throwback in some aspects of its instruction set design.
- panick21_ 2y ago
  Lets be real, its about business models. POWER was and is backed by IBM. ARM won on mobile. Does this mean POWER and ARM are better then MIPS, SPARC, PA-RISC, Am29000, i860? I don't think so.
- Symmetry 2y ago
  More details on how RISCy or CISCy various chips are: https://userpages.umbc.edu/~vijay/mashey.on.risc.html https://userpages.umbc.edu/~vijay/mashey.on.risc.html Notably x86 is one of the less CISCy CISCs so it looks like there might be a happy medium.

Joker_vD 2y ago

There was such dream. It was about getting the mind-bogglingly simple CPU, put caches into the now empty place where all the control logic used to be, and clock it up the wazoo, and let the software deal with load/branch delays, efficiently using all 64 registers, etc. That'll beat the hell out of those silly CISC architectures at performance, and at the fraction of the design and production costs! This didn't work out, for two main reasons: first, just being able to turn clocks hella high is still not enough to get great performance: you really do want your CPU to be super-scalar, out-of-order, and with great branch predictor, if you need amazing performance. But when you do all that, the simplicity of RISC decoding stops mattering all that much, as Pentium II demonstrated when it equalled DEC Alpha on performance, while still having practically useful things like e.g. byte loads/stores. Yes, it's RISC-like instructions under the hood but that's an implementation detail, no reason to expose it to the user in the ISA, just as you don't have to expose the branch delay slots in your ISA because it's a bad idea to do so: e.g. MIPS II added 1 additional pipeline stage, and now they needed two branch/load delay slots. Whoops! So they added interlocks anyway (MIPS originally stood for "Microprocessor without Interlocked Pipelined Stages", ha-ha) and got rid of the load delays; they still left 1 branch delay slot exposed due to backwards compatibility, and the circuitry required was arguably silly. The second reason was that the software (or compilers, to be more precise) can't really deal very well with all that stuff from the first paragraph. That's what sank Itanium. That's why nobody makes CPUs with register windows any more. And static instruction scheduling in the compilers still can't beat dynamic instruction reordering.

baq 2y ago
Great post as it is also directly applicable to invalidate the myth that the arm instruction set somehow makes the whole cpu better than analogous x86 silicon. It might be true and responsible for like 0.1% (guesstimate) of the total advantage; it's actually all RISC under the hood and both ISAs need decoders, x86 might need a slightly bigger one which amounts to accounting noise in terms of area. c.f. https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-matter/ https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-...
panick21_ 2y ago
> This didn't work out ... except it did. You had literal students design chips that outperformed industry cores that took huge teams and huge investment. Acorn had a team of just a few people build a core that outperformed an i460 with likely 1/100 investment. Not to mention the even more expensive VAX chips. Can you imagine how fucking baffled the DEC engineers at the time were when their absurdly complex and absurdly expensive VAX chip were smocked by a bunch of first time chip designers? > as Pentium II demonstrated That chip came out in 1997. The original RISC chip research happened in the early 80s or even earlier. It did work, its just that x86 was bound to the PC market and Intel had the finances huge teams hammer away at the problem. x86 was able to overtake Alpha because DEC was not doing well and they couldn't invest the required amount. > no reason to expose it to the user in the ISA Except that hidden the implementation is costly. If you give 2 equal teams the same amount of money, what results in a faster chip. A team that does a simply RISC instruction set. Or a team that does a complex CISC instruction set, transforms that into an underlying simpler instruction set? Now of course for Intel, they had backward comparability so they had to do what they had to do. They were just lucky they were able to invest so much more then all the other competitors.