IIRC the Open Genera folks said the Alpha RISC code to interpret the Symbolics instruction set, which fit in the Alpha's cache, ran about as fast as you'd expect microcode to run. So in a sense we're all writing microcode now?
It's probably worth reading this Alan Kay comment, which I excerpted from https://www.quora.com/Papers-about-the-Smalltalk-history-ref... on Quora before it started always blocking me as a robot:
> The idea of microcode was invented by Maurice Wilkes, a great
pioneer who arguably made the earliest programmable computer — the
EDSAC (pace Manchester Baby). The idea depends partly on the
existence of a “large enough” memory that is much faster (3–10
times) than the 1st level RAM of the computer.
> A milestone happened when the fast memory for microcoding was made
reloadable. s Now programmable functions that worked as quickly as
wired functions could be supplied to make a “parametric”
meta-machine. This technique was used in all of the Parc computers,
both mainframes and personal computers.
> Typical ratios of speed of microcode memory to RAM were about 5x or
more, and e.g the first Altos had 4kbytes (1k microinstructions)
that could be loaded on the fly. The Alto also had 16 program
counters into the microcode and a shared set of registers for doing
work. While running, conditions on the Alto — like a disk sector
passing, or horizontal retrace pulse on the CRT — were tied to the
program counters and these were concurrently scanned to determine
the program counter that would be used for the next
microinstruction. (We didn’t like or use “interrupts” … )
> This provided “zero-overhead tasking” at the lowest level of the
machine, and allowed the Alto to emulate almost everything that used
to be the province of wired hardware.
> This made the machine affordable enough that we were able to build
almost 2000 of them, and fast enough to do the functionality of
10–15 years in the future.
> Key uses of the microcode were in making suitable “language
machines” for the VHLLs we invented and used at Parc (including
Smalltalk, Mesa, etc.), doing real time high quality graphical and
auditory “animations/synthesis”, and to provide important systems
functions (e.g. certain kinds of memory management) as they were
invented.
> It’s worth looking at what could have been done with the early 16
bit VLSI CPUs such as the Intel 8086 or the Motorola 68K. These were
CISC architectures and were fast enough internally to allow a kind
of microcoding to support higher level language processing. This is
particularly important to separate what is a kind of interpreter
from having its code fetched from the same RAM it is trying to
emulate in.
> The 68K in fact, used a kind of “nano-coding”, which could have been
directed to reloadability and language processing.
> The big problem back then was that neither Intel nor Motorola knew
anything about software, and they didn’t want to learn (and they
didn’t).
> The nature of microcode is that architectures which can do it
resemble (and anticipated) the RISC architectures. And some of the
early supercomputers — like the CDC 6600 — were essentially RISC
architectures as well. So there was quite a bit of experience with
this way of thinking.
> In the 80s, the ratio between RAM and CPU cycles was closing, and
Moore’s Law was starting to allow more transistors per chip.
Accessing a faster memory off CPU chip started to pay off less
(because going off chip costs in various ways, including speed).
> Meanwhile, it was well known that caching could help most kinds of
architectures (a landmark study by Gordon Bell helped this
understanding greatly), and that — if you are going to cache — you
should have separate caches for instructions and for data.
> Up to a point, an instruction cache can act like a microcode memory
for emulating VHLLs. The keys are for it (a) to be large enough to
hold the inner loops of the interpreter, (b) to not be flushed
spuriously, and (c) for the machine instructions to execute quickly
compared to the cache memory cycle.
> Just to point the finger at Intel again, they did a terrible job
with their cached architectures, in part because they didn’t
understand what could be gained with VHLLs.
> A really interesting design was the first ARM — which was a pretty
clean RISC and tidy in size. It could have been used as an emulator
by wrapping it with fast instruction memory, but wasn’t. I think
this was a “point of view” disconnect. It was a very good design for
the purpose of its designers, and there wasn’t enough of a VHLL
culture to see how it could be used at levels much higher than C.
> If we cut to today, and look at the systems that could be much
better done, we find that the general architectures are still much
too much single level ones, that ultimately think that it is good to
have the lowest levels in a kind of old style machine code
programmed in a language like C.
> A very different way to look at it might be to say: well, we really
want zillions of concurrent and safe processes with very fast
intermessaging programmed at the highest levels — what kind of
architecture would facilitate that? We certainly don’t want either
“interrupts” or long latency process switching (that seems crazy to
“old Parc people”. We probably want to have “data” and “processing”
be really close to each other rather than separated in the early von
Neumann ways.
> And so forth. We won’t be able to be perfect in our hardware designs
or to anticipate every future need, so we must have ways to
restructure the lowest levels when required. One way to do this
these days is with FPGAs. And given what it costs to go off chips,
microcoding is far from dead as another way to help make the systems
that we desire.
> The simple sum up here is that “hardware is just software
crystallized early”, and a good systems designer should be able to
design at all levels needed, and have the chops to make any of the
levels if they can’t be purchased …