Hacker News Reader

Comment by Taniwha | Hacker News Reader

I think the big thing the RISC vs CISC wars articles always seem to miss or play down is the effect that large caches near or on-chip had in the way that people made trade offs in CPU design.

CISC (heavily encoded) instruction sets made sense when memory was very expensive (late 70s I worked somewhere where we spent >$US1M for 1.5Mb of actual core for a mainframe - reading a word took 1uS - reading an instruction was destructive, you had to write it back) heavily encoded instructions made sense because of the realities of the memory hierarchy.

As we started to move CPUs onto single chips the numbers started to change, RAS/CAS timers were ~1-300nS, caches in particular, initially off chip and eventually on chip were in the 10ns sorts of speeds, suddenly the tradeoffs between heavily encoding instructions to make them small and trading off decode time for fetch time were reasonable changes to make

View on HN

One notable point in there is that the thing that everyone things of when you say “RISC pipeline” (ie. MIPS) simply has to have an I-cache, because without it you simply do not have the memory bandwidth to do anything other than reading instructions.

Interesting historical fact there is that early ARM cores (and I suspect that Berkeley RISC is similar) are what one would today call CISC microarchitecture with the datapath strikingly similar to lets say m68k, but with significantly simpler sequencing logic.

I'm pretty sure the first generation MIPS/ARM/etc had off chip (but very close) caches

The point there is that for the “traditional” RISC pipeline you need to read 32b worth of instruction from somewhere every cycle. You cannot do that if the only thing you have is one 32b wide bus to the outside world. First ARMs solved this by somewhat complex sequencer and not that deep pipelining. Another thing is that anything off-chip is going to be at least two clock cycles as you do not want the however fast off-chip memory to be part of your critical path.

But well, many RISC designs had off-chip SRAM caches, sometimes even ridiculously large (PA-RISC is a prime example).

You can run a piped i-cache faster (with a branch penalty ... but those machines also often had delay slots ...)

I think ARM2 (the version used in the first Archimedes computers) had no cache on or off chip. ARM3 had 4KB of on-chip cache.

> Although the ARM2 employed by current models could reportedly be run at 20 MHz, it was only ever run at 8 MHz due to external limitations, these being the speed of the data bus and of the "relatively slow", but correspondingly relatively inexpensive, RAM devices in use. The ARM3 incorporated a 4 KB on-chip combined instruction and data cache, loosening such external constraints and thus permitting the processor to be run productively at the elevated 20 MHz frequency.

https://en.wikipedia.org/wiki/Acorn_Archimedes#ARM3_upgrades

Though it did support page mode DRAM.

> Another change, and among the most important in terms of practical real-world performance, was the modification of the instruction set to take advantage of page mode DRAM. Recently introduced, page mode allowed subsequent accesses of memory to run twice as fast if they were roughly in the same location, or "page", in the DRAM chip. Berkeley's design did not consider page mode and treated all memory equally. The ARM design added special vector-like memory access instructions, the "S-cycles", that could be used to fill or save multiple registers in a single page using page mode. This doubled memory performance when they could be used, and was especially important for graphics performance.

https://en.wikipedia.org/wiki/ARM_architecture_family#Design...

The instructions that took advantage of FPM DRAM already existed in ARM1, only the implementation was different. And exactly these instructions (that essentially do the RISC/SPARC-like register window shift as an explicit operation) are the reason why ARM should be ACM, as in Acorn CISC Machine.

I ignored the ARM1 as I thought it was more of a prototype.

> ARM1 was distributed as an evaluation system and was never commercialized.

https://en.wikichip.org/wiki/acorn/microarchitectures/arm1

> without it you simply do not have the memory bandwidth to do anything other than reading instructions.

And?

You only NEED instruction fetches when the values you are operating on are in registers -- because you have a lot of registers, function arguments and results are passed in registers, local variables are in registers, even the return address stays in a register for leaf functions (the vast majority of functions, dynamically.

Loads and stores are quite rare, and the majority of them are saving registers at the start of the function and reloading them at the end -- for which ARM provided load/store multiple instructions, the "CICSy" part of ARM (but not very .. it's a simple hardware sequencer) which they have dropped in Aarch64.

Wait, core as in magnetic core memory? Was there any advantage to still using it as late as the late 70s? Or was it an older mainframe? But in any case, your comment made me realize how little I know about that time period even if I'm super interested in it. Thanks for sharing!

Semiconductor memory was really really expensive until it hit the 16-64kbit/chip level and then it had a bit of a crisis because they suddenly all went a bit flaky (turned out to be alpha particles in the ceramic packages) - that was around about 1980 - at the time it was a bit of a mystery and people were wondering if memory would be able to get any denser and still be reliuable.

I think we bought our first 'big' machine with semiconductor memory around then (a Vax 11/780)

CISC vs RISC doesn't matter. An ISA should ideally be a healthy mixture of both (citation needed). Arm64 allows memory operands, "just" like x86; but it still has code size issues. Memory operands (ie having a bit of address calculation in the load that's fused into its use) are very useful for reducing register pressure, which is an issue that every call ABI must contend with. This is something that the RISC ISA totally misses (and ARM64.. isn't really RISC).

The issue with this "debate" is that it misses the forest for trees. Instead we should be talking about binary encoding (ie how much "variability" is required), and you're right on that bit; memory isn't the issue it once was.

> Arm64 allows memory operands, "just" like x86

Citation needed. It's a load/store ISA, with arithmetic taking place only register-to-register.

>CISC (heavily encoded) instruction sets made sense when memory was very expensive

That's assuming that CISC programs are smaller than RISC ones, which is not the case, at least for RISC ISAs with two instruction lengths (CDC6600, Cray 1, first IBM 801 version, RISC-II, and ARMv7 and RISC-V obviously)

Indeed, RISC was only possible because of a rather short era in the late 70s/early 80s when memory became fast enough to justify needing to fetch an instruction every clock cycle. If the cycle time of the CPU is lower than the memory, then it makes more sense for instructions to take more time but also do more.

...and now, CISC still makes sense because of the huge gap between core and memory speeds, accompanied by the many levels of caching in the middle. This is also very important for SMP since each core takes fetch bandwidth.

Reply on news.ycombinator.com