> The guiding theme, if there is/was one of CISC architectures was the ability for people to write assembly code. That's why there are all those string manipulation instructions and the like: think of those old instruction sets as basically ALU manipulation plus some convenience subroutines implemented in hardware/microcode.
> The breakthrough of the 801 was realizing that with the rise of compilers, those convenience features were no longer needed and all the work required to support them was wasted and could be jettisoned.
There's a deeper reason behind the change: the designers could assume ubiquitous instruction caches.
The majority of the benefit of microcode during the age of CISC supremacy was that these systems were true von Neumann systems, and every instruction fetch competed with the bus for a data access. The CISCy microcode gave you a pseudo harvard arch where say, your memset could use all of it's cycles actually moving data around.
Once ISA designers could assume I-caches, then now you can give everyone that pseudo harvard architecture benefit for any code they want to write, not just the routines you as the ISA designer think of ahead of time and put into ROM.
As an aside, this is probably what killed off the microcoded virtual machine archs like the lisp and smalltalk machines. Almost all of their benefit was that by putting the interpreter loop into microcode, it's ucode rom fetches didn't compete with the bytecode program and data fetches. Once an I-cache was present, anyone could write their own interpreter with the same properties without having to buy custom hardware. So it wasn't the C language ubiquity that killed them off, but the ubiquitous I-cache.
Never thought of the micromachine as a kind of harvard architecture (when I wrote microcode I just thought of the macroinstructions as data — this was back in the 80s) but it’s an interesting idea.
> As an aside, this is probably what killed off the microcoded virtual machine archs like the lisp and smalltalk machines.
The hardware provided other benefits (pointer and literal tagging, for example; also GC hardware). It wasn’t that C overwhelmed lisp, it was that other functional units on the workstation could provide similar functionality but with the hardware advantages of scale on a bigger customer base.
For example using the pager as a barrier for a transporting GC — essentially you are storing the tag bits in the TLB.
Also most people found interpreters weird (and still do), so speeding that up a little with custom hardware didn’t help many people.
Still, your point about the impact of the I cache is interesting.
It was heavily influenced by the original Lisp Machine (PDP-10) which had a simple, regular, and orthogonal instruction set, itself practically the first RISC machine.
If you look at the old Radin or Henessy papers, indeed the statement might seem far fetched. The PDP-6/10 did not start from the perspective of a powerful compiler, for example.
But the big machines of the 60s and 70s had lots of features (as I alluded to in my root comment) for developers, like BCD support (survived into x86) string manipulation, variable length instructions etc. Just look at the Sperry, IBM and other big machines of the time.
The ‘10s instruction set, as I noted above was quite regular and could be implemented in hardware (as it was in the KA at least): simple, regular, and easily predicted. Utterly the opposite of where the CISC guys were going.
Of course the whole CPU architecture of a machine like the KA was trivial by today’s standards, with no microarchitecture, so to some degree the simplicity of design was a bottom up constraint as well, and in that regard, to loop back to the top of this comment, was the opposite of the motivations that drove the idea of “reduce” in RISC
> The breakthrough of the 801 was realizing that with the rise of compilers, those convenience features were no longer needed and all the work required to support them was wasted and could be jettisoned.
There's a deeper reason behind the change: the designers could assume ubiquitous instruction caches.
The majority of the benefit of microcode during the age of CISC supremacy was that these systems were true von Neumann systems, and every instruction fetch competed with the bus for a data access. The CISCy microcode gave you a pseudo harvard arch where say, your memset could use all of it's cycles actually moving data around.
Once ISA designers could assume I-caches, then now you can give everyone that pseudo harvard architecture benefit for any code they want to write, not just the routines you as the ISA designer think of ahead of time and put into ROM.
As an aside, this is probably what killed off the microcoded virtual machine archs like the lisp and smalltalk machines. Almost all of their benefit was that by putting the interpreter loop into microcode, it's ucode rom fetches didn't compete with the bytecode program and data fetches. Once an I-cache was present, anyone could write their own interpreter with the same properties without having to buy custom hardware. So it wasn't the C language ubiquity that killed them off, but the ubiquitous I-cache.