The DEC Alpha AXP did this in something called PALcode. Unimplemented instructions generated a CPU interrupt that got handled by a PALcode emulator. If I recall correctly, one of the things it did was emulate byte-wise memory operations on older processors that could only do loads and stores on double-word- or quad-word-aligned memory addresses. It was quite a bit slower than having the requisite silicon inside the CPU itself, but I don't have the numbers available.

I miss the Alphas. Those machines were _awesome_.

A hardware instance of http://c2.com/cgi/wiki?DoesNotUnderstand.

Microcode is a special unit in the decoder. When a microcoded instruction is detected in the codestream, it is stopped and replaced by a stream of instructions from the microcode ROM.

Imaginary example:

mul 37 -1

Could be automatically identified and replaced with a predetermined codestream of:

add (not 37) 1

This allows super complicated instructions (of which x86 has many) to be implemented with simple instructions, and it also allows the designer to work around bugs that might be discovered later on.

That is the "x86 on RISC-ish core" interpretation of term microcode, which is probably not exactly correct as far as the actual implementations go.

As a technical term, microcode is contents of memory that is used to implement CPU sequencing (in contrast to doing sequencing in hardwired random logic or having essentially no sequencing logic as is the case in classical RISC designs). In most straightforward implementation it's essentially turing machine with microcode as state table and tape replaced by rest of the CPU. Various enhancements and modifications are possible which end in having essentially full-blown CPU for processing microcode, but even in that case one thing is critical for the term: the microcode only handles control functions (sequencing) and does not directly process data.

in x86, it's even worse - there are microcode translators, with the microcode running on special small ALUs, with their own code caches.