RISC vs. CISC by John R. Mashey (1995)
72 points by caned 1 year ago | 36 comments- drivebycomment 1 year agoWhoa. 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 1 year agoYeah 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 1 year agoUsenet 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)
- xarope 1 year ago
- trentnelson 1 year ago
- Symmetry 1 year agoThe 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 1 year agoIntel's new x86 extension (APX) is adding 16 more registers and three-register instructions. RISCification is still in progress.
- sapiogram 1 year agoWhat's RISC about adding more registers?
- ajross 1 year agoThe 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 1 year agoThe 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.
- ajross 1 year ago
- sapiogram 1 year ago
- snvzz 1 year ago>the RISCiest of the CISCs and the CISCiest of the RISCs. A happy medium.
Until RISC-V enters the conversation.
- thechao 1 year agoIf you actually dig into the details of RISC-V — especially the variable width extensions, it scratches all of my CISC-y itches just fine. Is it as CISC-y as ARM or x86? Not yet; not yet.
- thechao 1 year ago
- fanf2 1 year agoThe runner-up CISC, IBM z / 370, is also fairly RISCy.
- pclmulqdq 1 year agoThe runner-up RISC, IBM's POWER, is arguably more CISC-y than ARM.
- brucehoult 1 year agoI can't agree with that -- POWER has slightly simpler addressing modes, in that `lwu` etc are always and only pre-increment/decrement, and doesn't have load/store multiple (the most CISCy thing in arm32) at all. And also, obviously, not predication, either per-instruction or with anything like `IT*`.
- brucehoult 1 year ago
- pclmulqdq 1 year ago
- hmry 1 year ago
- netbioserror 1 year agoAs 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 1 year 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 1 year 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.
- zimpenfish 1 year ago> a future dominated by gigantic core counts of really simple cores that may even be in-order
Chuck Moore (of Forth fame) has been advocating something like this for a while, although he's more "multi-computer" than "multi-core".
- fanf2 1 year ago> I'm betting on a future dominated by gigantic core counts of really simple cores that may even be in-order.
¿Por qué no los dos? ¡CPU and GPU!
- gumby 1 year ago
- Pet_Ant 1 year ago
- 082349872349872 1 year agoLynn Wheeler is another oft-informative usenet personality.
- brucehoult 1 year agoOn IBM 360/370 etc stuff, at least.
- brucehoult 1 year ago
- klelatti 1 year agoSix hours and only two comments. Perhaps the RISC vs CISC debate is over :)
- DeathArrow 1 year agoI doubt there are many pure CISC architectures anymore. Most use micro instructions.
- Pet_Ant 1 year agoWas 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.
- chuckadams 1 year agoIBM mainframes used to be sold in tiers where the cheaper machines would implement more of the instruction set in microcode than the higher-end ones. I imagine even the top end had some amount of microcode kicking around though.
> a hardware virtual machine
Otherwise known as "a machine" :)
- 1 year ago
- drpossum 1 year agoThe 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
- chuckadams 1 year ago
- snvzz 1 year ago>Most use micro instructions.
That's a characteristic of the microarchitecture.
It has nothing to do with RISC or CISC.
- klelatti 1 year agoThey always did didn’t they?
- drpossum 1 year agoNot "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
- drpossum 1 year ago
- Pet_Ant 1 year ago
- 1 year ago
- DeathArrow 1 year ago