On 1/2/19 8:02 AM, Jon Elson via cctalk wrote:
Random logic instruction decode was a REAL issue in
about 1960 - 1965,
when computers were built with discrete transistors.? The IBM 7092, for
instance, had 55,000 transistors on 11,000 circuit boards.? I don't know
how much of that was instruction decode, but I'll guess that a fair bit
was.? The IBM 360's benefited from microcode, allowing them to have a
much more complex and orthogonal instruction set with less logic.
But, once ICs were available, the control logic was less of a problem.?
But, microcode still made sense, as memory was so slow that performance
was dictated by memory cycle time, and the microced did not slow the
system down.? Once fast cache became standard, then eliminating
performance bottlenecks became important.? And, once we went from lots
of SSI chips to implement a CPU to one big chip, then it was possible to
implement the control logic within the CPU chip efficiently.
I don't know--"microcode" in today's world is a very slippery term.
If
you're talking about vertical microcode, then I'm inclined to agree with
you. But even ARM, which is held up as the golden example of
microcode-less CPU design, is programmed via HDL, which is then compiled
into a hardware design, at least in instruction decoding. So ARM is a
programmed implementation. I suspect that if x86 microcode were to be
written out in HDL and compiled, Intel could make the same claim.
I think of it as being akin to "interpreted" vs. "compiled"
languages--the boundary can be rather fuzzy (e.g. "tokenizing",
"p-code", "incremental compilation"... etc.)
--Chuck