6 ms·

RISC vs. CISC by John R. Mashey (1995)

72 points by caned 2y ago

082349872349872 2y ago
Lynn Wheeler is another oft-informative usenet personality.
- brucehoult 2y ago
  On IBM 360/370 etc stuff, at least.
klelatti 2y ago
Six hours and only two comments. Perhaps the RISC vs CISC debate is over :)
- DeathArrow 2y ago
  I doubt there are many pure CISC architectures anymore. Most use micro instructions.
  - klelatti 2y ago
    They always did didn’t they?
    - drpossum 2y ago
      Not "always" but it has been around since at least the 70s, including the original 8086 which I don't think anyone would classify in good faith as RISC
  - Pet_Ant 2y ago
    Was there ever a CPU that didn't breakdown CISC instructions into uops, but instead had dedicated hardware for each operation? My understanding is that CISC assembly is really more like a bytecode for a hardware virtual machine.
    - deleted 2y ago
      [deleted]
    - drpossum 2y ago
      The venerable 6502. And if someone wants to argue that, it doesn't fit under the RISC definition in the post (which I like because it sets some good delineation) as it has features like indirect addressing and variable-length instruction sizes
      - monocasa 2y ago
        The 6502 has T states at least breaking instructions on memory access boundaries.
      - snvzz 2y ago
        >it has features like indirect addressing and variable-length instruction sizes There's nothing inherently non-RISC there. Indirect addressing was evaluated for RISC-V, and found to not be worth the required added complexity and encoding space. Whereas RISC-V actually adopted variable-length instruction size, because it was found to be highly beneficial to code density, and doable in a manner that does not add too much decode complexity, in neither small nor large micro-architectures.
        brucehoult 2y ago
        > Indirect addressing was evaluated for RISC-V, and found to not be worth the required added complexity and encoding space. wtf? If it was ever suggested by someone (and would NEVER be by Krste, Andrew, Yunsup, or Dave) then any evaluation would take less than 1 second before the "HELL NO!" > Whereas RISC-V actually adopted variable-length instruction size TWO instructions sizes, in the currently ratified ISA. And you can tell the size by looking at just 2 bits in the first byte of the instruction (the LSBs). That is very far from "variable-length" in the sense of VAX or M68k or x86. > ... was found to be highly beneficial to code density, and doable in a manner that does not add too much decode complexity Commercially known in microprocessors since at least SuperH 2A and Arm Thumb2. Not to mention 3 lengths (2, 4 or 6 bytes) in IBM 360, also decodable from just 2 bits in the instruction. Also CDC 6600 (arguably the first RISC), Cray-1 (also recognizably RISC), the first version of IBM 801, and Berkeley RISC-II (obviously familar to the RISC-V designers).
  - snvzz 2y ago
    >Most use micro instructions. That's a characteristic of the microarchitecture. It has nothing to do with RISC or CISC.
- deleted 2y ago
  [deleted]
netbioserror 2y ago
As I understand it, Intel apparently experimented with drastically lowering power consumption. They found that x86 chips can absolutely be made to sip power like ARM chips can. The conclusion was that fetch, decode, and interconnect were the most important power consumers, and CISC vs RISC didn’t quite matter as much as the physical architecture and layout. Am I remembering that correctly? Does anyone have a link?
- Pet_Ant 2y ago
  > The conclusion was that fetch, decode, and interconnect were the most important power consumers and CISC vs RISC didn’t quite matter as much Wouldn't that mean that x86 and other CISCs would cost more as they often have variable length instructions and thus the most complexity and consume the most power? Now, if you told me that scheduling uops and reordering uops etc consumed the most power, then I'd understand why RISC vs CISC wouldn't matter as at uop level are high performance chips are similar VLIW computers (AFAICT, IANACD). Though, for my money, I'm betting on a future dominated by gigantic core counts of really simple cores that may even be in-order. The extra transistors to speed up the processing are probably better spent on another core that can just handle the next request instead. Clock speeds brought down to some integer multiple of RAM speeds, and power costs brought down. At cloud scale this just seems economically inevitable. After that, the economies of scale mean it'll trickle down to everyone else except for specialised use cases. I believe we already seeing this happening with Zen C cores and Intel e cores, and that a simplified instruction set lie RISC-V will eventually win out for savings alone.
  - gumby 2y ago
    > on a future dominated by gigantic core counts of really simple cores that may even be in-order. The extra transistors to speed up the processing are probably better spent on another core that can just handle the next request instead. I like how you think, but not sure we can get there. Part of the RISC dream is that you shouldn’t need reordering as the ops should be similar in timing, so you could partially get there on that (although…look at divide, which IIRC the 801 didn’t even have). So they aren’t really uniform in length even before you consider memory issues. Then there is memory — not all references can be handled before instruction decode because a computed indirect reference requires computation from the ALU and register state to perform. You can’t just send the following instruction to another unit as its computation may depend on the instruction you’re waiting for. That’s why the instruction decode-and-perform has been smashed into lots of duplicated bits: to do what you say but on the individual steps. At a different level of granularity, big.LITTLE is an approach that’s along your line of thinking. We tend to have a lot more computation than we need, even at the embedded level, these days and we may end up with some tiny power-sipping coprocessors that dominate most of the runtime of a device while doing almost nothing.
Symmetry 2y ago
The end result seems to be that the two entries from that old post that have seen the most success, x86 and ARM, are essentially the RISCiest of the CISCs and the CISCiest of the RISCs. A happy medium.
- hmry 2y ago
  Intel's new x86 extension (APX) is adding 16 more registers and three-register instructions. RISCification is still in progress.
  - sapiogram 2y ago
    What's RISC about adding more registers?
    - ajross 2y ago
      The simple answer is that a big symmetric register set has always been a hallmark of RISC ISAs, because having lots of symmetric registers increases throughput by reducing compiler-generated spill/fill overhead and permits more permissive ABIs for leaf functions that need the extra space. The complicated answer is that, no, it's not especially "reduced" and you could implement all those other RISCy ideas in a much smaller set of GPRs without otherwise effecting the "RISCiness" of the design. But that answer is a little specious, since it's true of all the other RISCy traits too. Most of them stand alone, which is why the whole debate tends to be a little silly.
    - Symmetry 2y ago
      The name "RISC" is something we gave to a particular design philosophy, but not everything in that philosophy is summed up in the name. Classic RISC designs have 32 registers to make up for the lack of instructions that operate directly on memory addresses and to make things easier for the compiler and achieve good performance without load-op-store instructions.
- fanf2 2y ago
  The runner-up CISC, IBM z / 370, is also fairly RISCy.
drivebycomment 2y ago
Whoa. Comp.arch. I learned so much from that during 90s. There's nothing like debates with anecdotes thrown between experienced folks to learn from, and comp.arch back then had such a high signal-noise ratio that it was amazing.
- trentnelson 2y ago
  Yeah I was thinking how different those days seemed. And how hard it would be to run into this sort of content these days if you’re a generally curious youngster.
  - xarope 2y ago
    Usenet was prevalent in those days for those who had internet, which probably meant a lot of academic institutes (and then those of us who had 2400 baud modems). So it would make sense that like-minded people would subscribe to those news feeds. I'm not a social media expert, but with mastadon, blue sky, discord, even reddit (although perhaps the latter is now on a downward spiral; slashdot used to be one such too) with their specialised servers/forums etc, maybe there are still high signal-to-noise forums (HN is probably one such)

72 points by caned 2y ago

082349872349872 2y ago

Lynn Wheeler is another oft-informative usenet personality.

brucehoult 2y ago
On IBM 360/370 etc stuff, at least.

klelatti 2y ago

Six hours and only two comments. Perhaps the RISC vs CISC debate is over :)

DeathArrow 2y ago
I doubt there are many pure CISC architectures anymore. Most use micro instructions.
- klelatti 2y ago
  They always did didn’t they?
  - drpossum 2y ago
    Not "always" but it has been around since at least the 70s, including the original 8086 which I don't think anyone would classify in good faith as RISC
- Pet_Ant 2y ago
  Was there ever a CPU that didn't breakdown CISC instructions into uops, but instead had dedicated hardware for each operation? My understanding is that CISC assembly is really more like a bytecode for a hardware virtual machine.
  - deleted 2y ago
    [deleted]
  - drpossum 2y ago
    The venerable 6502. And if someone wants to argue that, it doesn't fit under the RISC definition in the post (which I like because it sets some good delineation) as it has features like indirect addressing and variable-length instruction sizes
    - monocasa 2y ago
      The 6502 has T states at least breaking instructions on memory access boundaries.
    - snvzz 2y ago
      >it has features like indirect addressing and variable-length instruction sizes There's nothing inherently non-RISC there. Indirect addressing was evaluated for RISC-V, and found to not be worth the required added complexity and encoding space. Whereas RISC-V actually adopted variable-length instruction size, because it was found to be highly beneficial to code density, and doable in a manner that does not add too much decode complexity, in neither small nor large micro-architectures.
      - brucehoult 2y ago
        > Indirect addressing was evaluated for RISC-V, and found to not be worth the required added complexity and encoding space. wtf? If it was ever suggested by someone (and would NEVER be by Krste, Andrew, Yunsup, or Dave) then any evaluation would take less than 1 second before the "HELL NO!" > Whereas RISC-V actually adopted variable-length instruction size TWO instructions sizes, in the currently ratified ISA. And you can tell the size by looking at just 2 bits in the first byte of the instruction (the LSBs). That is very far from "variable-length" in the sense of VAX or M68k or x86. > ... was found to be highly beneficial to code density, and doable in a manner that does not add too much decode complexity Commercially known in microprocessors since at least SuperH 2A and Arm Thumb2. Not to mention 3 lengths (2, 4 or 6 bytes) in IBM 360, also decodable from just 2 bits in the instruction. Also CDC 6600 (arguably the first RISC), Cray-1 (also recognizably RISC), the first version of IBM 801, and Berkeley RISC-II (obviously familar to the RISC-V designers).
- snvzz 2y ago
  >Most use micro instructions. That's a characteristic of the microarchitecture. It has nothing to do with RISC or CISC.
deleted 2y ago
[deleted]

netbioserror 2y ago

As I understand it, Intel apparently experimented with drastically lowering power consumption. They found that x86 chips can absolutely be made to sip power like ARM chips can. The conclusion was that fetch, decode, and interconnect were the most important power consumers, and CISC vs RISC didn’t quite matter as much as the physical architecture and layout. Am I remembering that correctly? Does anyone have a link?

Pet_Ant 2y ago
> The conclusion was that fetch, decode, and interconnect were the most important power consumers and CISC vs RISC didn’t quite matter as much Wouldn't that mean that x86 and other CISCs would cost more as they often have variable length instructions and thus the most complexity and consume the most power? Now, if you told me that scheduling uops and reordering uops etc consumed the most power, then I'd understand why RISC vs CISC wouldn't matter as at uop level are high performance chips are similar VLIW computers (AFAICT, IANACD). Though, for my money, I'm betting on a future dominated by gigantic core counts of really simple cores that may even be in-order. The extra transistors to speed up the processing are probably better spent on another core that can just handle the next request instead. Clock speeds brought down to some integer multiple of RAM speeds, and power costs brought down. At cloud scale this just seems economically inevitable. After that, the economies of scale mean it'll trickle down to everyone else except for specialised use cases. I believe we already seeing this happening with Zen C cores and Intel e cores, and that a simplified instruction set lie RISC-V will eventually win out for savings alone.
- gumby 2y ago
  > on a future dominated by gigantic core counts of really simple cores that may even be in-order. The extra transistors to speed up the processing are probably better spent on another core that can just handle the next request instead. I like how you think, but not sure we can get there. Part of the RISC dream is that you shouldn’t need reordering as the ops should be similar in timing, so you could partially get there on that (although…look at divide, which IIRC the 801 didn’t even have). So they aren’t really uniform in length even before you consider memory issues. Then there is memory — not all references can be handled before instruction decode because a computed indirect reference requires computation from the ALU and register state to perform. You can’t just send the following instruction to another unit as its computation may depend on the instruction you’re waiting for. That’s why the instruction decode-and-perform has been smashed into lots of duplicated bits: to do what you say but on the individual steps. At a different level of granularity, big.LITTLE is an approach that’s along your line of thinking. We tend to have a lot more computation than we need, even at the embedded level, these days and we may end up with some tiny power-sipping coprocessors that dominate most of the runtime of a device while doing almost nothing.

Symmetry 2y ago

The end result seems to be that the two entries from that old post that have seen the most success, x86 and ARM, are essentially the RISCiest of the CISCs and the CISCiest of the RISCs. A happy medium.

hmry 2y ago
Intel's new x86 extension (APX) is adding 16 more registers and three-register instructions. RISCification is still in progress.
- sapiogram 2y ago
  What's RISC about adding more registers?
  - ajross 2y ago
    The simple answer is that a big symmetric register set has always been a hallmark of RISC ISAs, because having lots of symmetric registers increases throughput by reducing compiler-generated spill/fill overhead and permits more permissive ABIs for leaf functions that need the extra space. The complicated answer is that, no, it's not especially "reduced" and you could implement all those other RISCy ideas in a much smaller set of GPRs without otherwise effecting the "RISCiness" of the design. But that answer is a little specious, since it's true of all the other RISCy traits too. Most of them stand alone, which is why the whole debate tends to be a little silly.
  - Symmetry 2y ago
    The name "RISC" is something we gave to a particular design philosophy, but not everything in that philosophy is summed up in the name. Classic RISC designs have 32 registers to make up for the lack of instructions that operate directly on memory addresses and to make things easier for the compiler and achieve good performance without load-op-store instructions.
fanf2 2y ago
The runner-up CISC, IBM z / 370, is also fairly RISCy.

drivebycomment 2y ago

Whoa. Comp.arch. I learned so much from that during 90s. There's nothing like debates with anecdotes thrown between experienced folks to learn from, and comp.arch back then had such a high signal-noise ratio that it was amazing.

trentnelson 2y ago
Yeah I was thinking how different those days seemed. And how hard it would be to run into this sort of content these days if you’re a generally curious youngster.
- xarope 2y ago
  Usenet was prevalent in those days for those who had internet, which probably meant a lot of academic institutes (and then those of us who had 2400 baud modems). So it would make sense that like-minded people would subscribe to those news feeds. I'm not a social media expert, but with mastadon, blue sky, discord, even reddit (although perhaps the latter is now on a downward spiral; slashdot used to be one such too) with their specialised servers/forums etc, maybe there are still high signal-to-noise forums (HN is probably one such)