RISC vs. CISC by John R. Mashey (1995)
yarchive.net
yarchive.net
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)
POWER has instructions like RLIMI, DOZ, and STHBRX on the "complex" side.
The RISC/CISC distinction is not just about addressing and accessing memory (register-register vs register-memory operations). The headline operations for x86 actually were more about the compute side rather than the memory side - things like the "AAD" instruction did a lot of computing work in one bite. There were also RISC register-memory machines at the time the distinction was meaningful.
No way. Quite the opposite. ARM64 is quite similar to e.g. RISC-V in most respects other than the use of condition codes.
> POWER has instructions like RLIMI, DOZ, and STHBRX on the "complex" side.
There is nothing complex or "un-RISC" about any of those.
RLIMI is similar to Arm32 BFI or Arm64 UBFM.
DOZ is just subtract with the output zeroed if the MSB is 1. It is easily implemented with just a handful of straight-line instructions in any ISA with min/max or slt or for that matter asr i.e. in hardware with a simple combinatorial add-on to standard subtraction.
STHBRX is just a little-endian store (on big-endian POWER). Plenty of other RISC ISAs (whether big-endian or little-endian) have that.
> things like the "AAD" instruction did a lot of computing work in one bite
Less than other ISAs with a one-shot decimal add instruction (or mode e.g. 6502). Once again, it's a very simple combinatorial circuit -- no CISCy microcode or control flow needed.
> There were also RISC register-memory machines at the time the distinction was meaningful.
Name one.
"General comment: this may sound weird, but in the long term, it might be easier to deal with a really complicated bunch of instruction formats, than with a complex set of addressing modes, because at least the former is more amenable to pre-decoding into a cache of decoded instructions that can be pipelined reasonably, whereas the pipeline on the latter can get very tricky (examples to follow)."
So the distinction is more about how 'easy' an ISA lends itself to pipelining (critical paths, dependencies between instructions/operands & so on), than about how rich the instruction set is or how much work 1 instruction may do.
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.
Until RISC-V enters the conversation.
Am I remembering that correctly? Does anyone have a link?
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.
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.
Chuck Moore (of Forth fame) has been advocating something like this for a while, although he's more "multi-computer" than "multi-core".
¿Por qué no los dos? ¡CPU and GPU!
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.
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).
And yes, RISC-V designers believe that addressing more complex than base+offset is a net loss in processor efficiency. You might need very slightly fewer instructions overall in a program, but it costs more transistors, silicon, and therefore dollars, and might even lower the achievable clock speed by more than the saved instructions.
Some companies implementing RISC-V don't quite believe that (e.g. Andes, THead) and add more complex addressing modes as custom extensions. Once they've spent the silicon then you might as well use it -- same with WCH's shadow registers or automatic push/pop for interrupt handling (depending on the core) -- but it's not proven it's actually the best use of additional silicon [1].
Let the market decide.
If complex addressing wins then RISC-V always has the possibility to add a standard extension. It's much harder to take unneeded features away.
[1] admittedly the equation is different with a single-core microcontroller in a package, vs a chip with large numbers of cores (whether all the same, or all RISC-V, or not). On a stand-alone microcontroller the die size is often determined by fitting the pads around the outside, and if you don't use all the silicon inside that then it's wasted.
> a hardware virtual machine
Otherwise known as "a machine" :)
That's a characteristic of the microarchitecture.
It has nothing to do with RISC or CISC.