>Patterson and colleagues first looked to build a modified RISC design to run the Smalltalk programming language (in a project known as SOAR, for Smalltalk On A RISC) and then to form the basis of a desktop workstation (known as SPUR, for Symbolic Processing Using RISC).
"The restricted processor count also allows us to build powerful RISC processors, which include support for Lisp and IEEE floating-point, at reasonable cost."
"SPUR features include a large virtually-tagged cache, address translation without a translation buffer, LISP support with datatype tags but without microcode..."
Another thing that was somewhat relevant at the time was ability to do arithmetic directly on tagged fixnum values. For example SPARC includes (somewhat unusable unless you write the Lisp implementation as a whole OS) instructions for that.
I dislike the framing of this period as "wars" but understand the colloquialism.
We are entering another interesting period with people building RISCV processors and SoCs on budget FPGA hardware. The distance between a working FPGA design and a working bit of custom silicon is a lot shorter than the distance between a simulated design and silicon. What I find amusing however is that we don't have a big "killer app" like the PC was at the time. We have cutthroat cost reduced embedded designs which are unforgiving.
Still, if you are someone who dreamed of designing your own bespoke processor architecture, now is a great time to be alive.
I think we do, though at a layer down the stack: do more at the edge using less power in the process. Just as the CPU<->memory pipeline lead to all sorts of interesting on-chip development (huge multi level cache architectures) network bandwidth in portable devices will increasingly be a bottleneck (it takes power to run the radio, and more and more devices will be competing for that bandwidth).
Another thing that's different is the concentration of compute within a few big vendors like AWS, Azure, GCP. That makes it easier to introduce new server chips, as you don't have to convince as many different customers. And the big 3 can abstract away some of the work.
the real downside of this market dynamic is that if you can't get one of those players interested in your product - you don't have a business. and if one of those deep pocketed agents feels like replicating your work instead of buying it - not much you can do.
overall I think this means a lot less interesting work lower down in the stack
It's interesting to look at two early development highlighted early in the article. The first was register windows: one of those "seems like a good idea at first", but which turned out to be not worth the transistors. You can understand the motivation: memory access was slow and expensive and IIRC the cache architectures of the day, when there even was one, were commonly just an I-cache or a D-cache even though the machines were von Neumann devices.
OTOH the lack of interlock was a kind of inverse: why waste transistors on something known at compile time anyway (same motivation for delay slots in branches, another idea that turned out not to be worth it). In reality, computation is dynamic, so runtime branch prediction (and later speculative execution) turned out to be a much better performance win, regardless of the design cost.
Edited to remove a comment about the 801, to which the author replied below.
Author here. Thanks for the comment and feedback. Really interesting point on MIPS vs RISC-I approaches.
I was a bit puzzled by the IBM 801 comment as the second para of the previous post mentions the 801 and links to an earlier post that is all about the 801. Was there something you think I missed in these earlier posts?
That didn't show as a link when I read it (shows as a link on my current device). Apologies for the oversight; I edited my comment.
The 801 was an insightful jump from then-current trends in processor design and that insight, to me, is what RISC is all about. There were lean and orthogonal instruction sets already (most notably, to me, the PDP-6/10 and Seymour Cray's work at CDC) but the central idea of offloading a lot of heavy lifting to the compiler (and recognizing Multics' insight of writing an OS in a HLL, pointing to a practically assembly-language free future) was groundbreaking, a kind of Special Relativity of computing.
Hi thanks so much for editing the comment. Much appreciated.
Completely agree with your succinct summary of the what RISC is all about and the 801's place in the story. I've heard others call Cray's CDC's computers the first RISC designs, which I don't think is quite right. Probably deserves a fuller explanation than I can manage here though!
A good post, though I have a couple of minor criticisms:
> Nobody writes assembly code any more, except when they do,
His very first sentence turns out to be the primary assumption of RISC: essentially nobody writes assembly code so don't worry about making that easy, and depend on the HLL compiler to do a lot of heavy lifting. The small amount of assembly is just to boot the processor, boot a process, and some small glue in the OS, and as that stuff is heavily used but almost never written you don't have to worry about alleviating those peoples' suffering.
Oh, and compiler and debugger writers, and he does point out how some of these decisions make things more complex for them!
> CISC had always involved decoding instructions into micro-instructions.
That isn't actually true; into the 60s instructions were implemented in hardware, and the roots of CISC lie there -- essentially some quintessentially CISC instructions (BCD support, string handling, etc) were subroutines implemented in hardware because they were so common and that made the computer easier to sell. (as an aside: back in those days, when the machines had high level languages they were often unique to the vendor or even the specific machine model!)
Then again, even tiny machines like the 8080 that weren't really RISC or CISC had microcode, but that was later.
The 8080 has nothing resembling microcode, and neither do the 8085 nor Z80. They're all based on an instruction decode PLA with a simple sequencer/state machine logic. Perhaps you're thinking of the 8086?
I was reading today about AMD 29000 and it came to my attention that a register windows wasn't a such a bad idea but having a fixed window size (as SPARC did) definitely was.
> Modern ARM RISC processors have multitudes more instructions than that of prior generation CISC processors.
That isn't and wasn't the thing that RISC processors reduced.
What was reduced was the complexity of the instructions themselves, not the number of instructions. For example, having complex addressing modes is CISC, whereas only touching the ALU in register-register operations is RISC; the theme is improved pipelineability, so you want less ALU state to have to back out if the memory operation takes a page fault. A number of things (delay slots, for example) follow from that focus on making the instructions as simple and pipelinable as possible.
Here's a guy who helped design MIPS on the distinction:
486 vs ARM is a good comparison as both are the extreme cases of CISC and RISC designs. So much that for a real instruction mix generated by reasonably modern compilers (think gcc3 and up), 486 is actually more of an RISC than ARM with its bunch of variants of ldm/stm.
> all instructions should be the same size in classic RISC.
IIRC yes, and also I think it's a matter of (at least in classical RISC designs) all instructions being fairly simple and being of close enough latency that, for the most part, instructions had a very close delay.
Contrast to something like x86 where some instructions were fast but others were far far slower.
The advantage of this was that pipelines would be easier to do, and while you would need more instructions to complete some tasks, the simplified processor designs would be easier to improve upon.
Oh, the other advantage was, this was easier to pipeline but would in many cases result in the dreaded 'branch delay slot' where an instruction after a branch would be done, even if the branch was taken[0]
And, in some ways that proved true in it's own right. The AMD K5 was based on an AMD Am29000 CPU with an X86 Decoding front end, (The NexGen 5x86 was as well, and did it -first- but AFAIK had a more 'purpose built' RISC core, The Pentium Pro I assume also had a 'purpose built' core, so the lineage is, at least most -easily- traceable with the K5.)
[0] - The connection between Branch Delay Slots in RISC architectures and speculative execution and pipeline vulnerabilities such as Spectere/Meltdown feels under explored, IMO there is a relation.
> I agree; all instructions should be the same size in classic RISC
That was not true for the original RISC ISAs -- CDC6600, Cray 1, IBM 801, RISC-II -- and it is not true now for ARMv7 and RISC-V.
It is only really true for RISC ISAs introduced between about 1985 and 1990.
And Aarch64, where it will come to be recognised as a mistake, in time.
> The quantity of instructions is not as relevant.
True.
A minimal but powerful ISA is a good thing, but it's not the differentiator between RISC and not-RISC. The complexity of each individual instruction is.
I tend to call ARM a load/store architecture to emphasise that difference and it seems to get my point across without derailing the conversation into a RISC-or-not debate.
(Note that I'm endorsing this as working in human to human communication rather than for absolute correctness)
"That isn't and wasn't the thing that RISC processors reduced."
Yes, it was, it literally was. Which addressing mode are you referring? Address calculation mode, or operand accessing mode? Because you have NO IDEA what you're taking about.
RISC original idea was all instructions would execute in a single tick. They had a load-store design, everything was hard-wired, and there would be no multi-step operations, and there would be ZERO microcode.
* ARM has microcode, everything is not hard-wired
* ARM has multi-tick instructions
The only thing ARM has that is RISC is load-store, and now there are multiple prefetch load-stores, which absolutely goes against the grain of original RISC mentality.
By RISC processor standards of the 1970s-1990s, ARM is not a RISC processor.
A load-store design is where operations are loaded into the registers. What this means is you have to load the operands into the registers, they don't come from memory.
A register-memory design is one where the operands can come from memory as well. This was the case for CISC in the 1980s, and 1990s. Not the case anymore. AVX is great example, Certain instructions can, and cannot be executed in this manner.
The ARM has predication, which IS NOT RISC. The ARM uses microcode, which is not RISC.
There are no pure RISC processors being designed today, in-which the original concepts Hennessy outlined. The lines between architectures are blurred.
I like how you take one thing, and then claim that makes it RISC. No it doesn't. The 80486 CISC was more RISC like than the modern ARM.
Can goal posts move? Yes. But what exists today are blurred amalgamations of both CISC and RISC. There are no pure CISC CPU's, as there are no pure RISC CPU's.
RISC was intended to have fewer instructions to allow reduced execution time, and higher clock speeds. The addressing mode did not define RISC, it was a method to reach the goal. That link has a lot of wrong information about RISC.
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
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.
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).
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.
> 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.
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.
> 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)
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.
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
...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.
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.
>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)
48 comments
[ 3.6 ms ] story [ 119 ms ] thread"The restricted processor count also allows us to build powerful RISC processors, which include support for Lisp and IEEE floating-point, at reasonable cost."
"SPUR features include a large virtually-tagged cache, address translation without a translation buffer, LISP support with datatype tags but without microcode..."
We are entering another interesting period with people building RISCV processors and SoCs on budget FPGA hardware. The distance between a working FPGA design and a working bit of custom silicon is a lot shorter than the distance between a simulated design and silicon. What I find amusing however is that we don't have a big "killer app" like the PC was at the time. We have cutthroat cost reduced embedded designs which are unforgiving.
Still, if you are someone who dreamed of designing your own bespoke processor architecture, now is a great time to be alive.
I think we do, though at a layer down the stack: do more at the edge using less power in the process. Just as the CPU<->memory pipeline lead to all sorts of interesting on-chip development (huge multi level cache architectures) network bandwidth in portable devices will increasingly be a bottleneck (it takes power to run the radio, and more and more devices will be competing for that bandwidth).
overall I think this means a lot less interesting work lower down in the stack
OTOH the lack of interlock was a kind of inverse: why waste transistors on something known at compile time anyway (same motivation for delay slots in branches, another idea that turned out not to be worth it). In reality, computation is dynamic, so runtime branch prediction (and later speculative execution) turned out to be a much better performance win, regardless of the design cost.
Edited to remove a comment about the 801, to which the author replied below.
I was a bit puzzled by the IBM 801 comment as the second para of the previous post mentions the 801 and links to an earlier post that is all about the 801. Was there something you think I missed in these earlier posts?
That didn't show as a link when I read it (shows as a link on my current device). Apologies for the oversight; I edited my comment.
The 801 was an insightful jump from then-current trends in processor design and that insight, to me, is what RISC is all about. There were lean and orthogonal instruction sets already (most notably, to me, the PDP-6/10 and Seymour Cray's work at CDC) but the central idea of offloading a lot of heavy lifting to the compiler (and recognizing Multics' insight of writing an OS in a HLL, pointing to a practically assembly-language free future) was groundbreaking, a kind of Special Relativity of computing.
Completely agree with your succinct summary of the what RISC is all about and the 801's place in the story. I've heard others call Cray's CDC's computers the first RISC designs, which I don't think is quite right. Probably deserves a fuller explanation than I can manage here though!
https://www.jwhitham.org/2016/02/risc-instruction-sets-i-hav...
> Nobody writes assembly code any more, except when they do,
His very first sentence turns out to be the primary assumption of RISC: essentially nobody writes assembly code so don't worry about making that easy, and depend on the HLL compiler to do a lot of heavy lifting. The small amount of assembly is just to boot the processor, boot a process, and some small glue in the OS, and as that stuff is heavily used but almost never written you don't have to worry about alleviating those peoples' suffering.
Oh, and compiler and debugger writers, and he does point out how some of these decisions make things more complex for them!
> CISC had always involved decoding instructions into micro-instructions.
That isn't actually true; into the 60s instructions were implemented in hardware, and the roots of CISC lie there -- essentially some quintessentially CISC instructions (BCD support, string handling, etc) were subroutines implemented in hardware because they were so common and that made the computer easier to sell. (as an aside: back in those days, when the machines had high level languages they were often unique to the vendor or even the specific machine model!)
Then again, even tiny machines like the 8080 that weren't really RISC or CISC had microcode, but that was later.
That isn't and wasn't the thing that RISC processors reduced.
What was reduced was the complexity of the instructions themselves, not the number of instructions. For example, having complex addressing modes is CISC, whereas only touching the ALU in register-register operations is RISC; the theme is improved pipelineability, so you want less ALU state to have to back out if the memory operation takes a page fault. A number of things (delay slots, for example) follow from that focus on making the instructions as simple and pipelinable as possible.
Here's a guy who helped design MIPS on the distinction:
https://userpages.umbc.edu/~vijay/mashey.on.risc.html
The quantity of instructions is not as relevant.
IIRC yes, and also I think it's a matter of (at least in classical RISC designs) all instructions being fairly simple and being of close enough latency that, for the most part, instructions had a very close delay.
Contrast to something like x86 where some instructions were fast but others were far far slower.
The advantage of this was that pipelines would be easier to do, and while you would need more instructions to complete some tasks, the simplified processor designs would be easier to improve upon.
Oh, the other advantage was, this was easier to pipeline but would in many cases result in the dreaded 'branch delay slot' where an instruction after a branch would be done, even if the branch was taken[0]
And, in some ways that proved true in it's own right. The AMD K5 was based on an AMD Am29000 CPU with an X86 Decoding front end, (The NexGen 5x86 was as well, and did it -first- but AFAIK had a more 'purpose built' RISC core, The Pentium Pro I assume also had a 'purpose built' core, so the lineage is, at least most -easily- traceable with the K5.)
[0] - The connection between Branch Delay Slots in RISC architectures and speculative execution and pipeline vulnerabilities such as Spectere/Meltdown feels under explored, IMO there is a relation.
How close was AMD's RISC to SPARC?
It had register windows. Was it SPARC?
https://en.m.wikipedia.org/wiki/AMD_Am29000
That was not true for the original RISC ISAs -- CDC6600, Cray 1, IBM 801, RISC-II -- and it is not true now for ARMv7 and RISC-V.
It is only really true for RISC ISAs introduced between about 1985 and 1990.
And Aarch64, where it will come to be recognised as a mistake, in time.
> The quantity of instructions is not as relevant.
True.
A minimal but powerful ISA is a good thing, but it's not the differentiator between RISC and not-RISC. The complexity of each individual instruction is.
(Note that I'm endorsing this as working in human to human communication rather than for absolute correctness)
Yes, it was, it literally was. Which addressing mode are you referring? Address calculation mode, or operand accessing mode? Because you have NO IDEA what you're taking about.
RISC original idea was all instructions would execute in a single tick. They had a load-store design, everything was hard-wired, and there would be no multi-step operations, and there would be ZERO microcode.
* ARM has microcode, everything is not hard-wired * ARM has multi-tick instructions
The only thing ARM has that is RISC is load-store, and now there are multiple prefetch load-stores, which absolutely goes against the grain of original RISC mentality.
By RISC processor standards of the 1970s-1990s, ARM is not a RISC processor.
A load-store design is where operations are loaded into the registers. What this means is you have to load the operands into the registers, they don't come from memory.
A register-memory design is one where the operands can come from memory as well. This was the case for CISC in the 1980s, and 1990s. Not the case anymore. AVX is great example, Certain instructions can, and cannot be executed in this manner.
The ARM has predication, which IS NOT RISC. The ARM uses microcode, which is not RISC.
There are no pure RISC processors being designed today, in-which the original concepts Hennessy outlined. The lines between architectures are blurred.
I like how you take one thing, and then claim that makes it RISC. No it doesn't. The 80486 CISC was more RISC like than the modern ARM.
Can goal posts move? Yes. But what exists today are blurred amalgamations of both CISC and RISC. There are no pure CISC CPU's, as there are no pure RISC CPU's.
Therefore, you have nothing to say.
And the goal was pipelineability, not having fewer instructions.
> That link has a lot of wrong information about RISC.
The guy who helped design one of the more successful RISC chips doesn't know anything about RISC chips? OK.
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
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.
But well, many RISC designs had off-chip SRAM caches, sometimes even ridiculously large (PA-RISC is a prime example).
> 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...
> ARM1 was distributed as an evaluation system and was never commercialized.
https://en.wikichip.org/wiki/acorn/microarchitectures/arm1
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.
I think we bought our first 'big' machine with semiconductor memory around then (a Vax 11/780)
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
...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.
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.
Citation needed. It's a load/store ISA, with arithmetic taking place only register-to-register.
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)