> early microprocessors such as the 6502 and Z-80 didn't use microcode
If you look at a die shot of the 6502, for example, you will see an area that looks confusingly similar to where microcode would be stored. Turns out, this is a PLA, not a microcode store. The best quick intro to microcoding that I have encountered is https://people.cs.clemson.edu/~mark/uprog.html.
So where's the line drawn between instruction decoding, and microcoding? It sounds like microcoding is when a single instruction in the program resolves to a _sequence_ of operations that the processor executes?
There is one important practical criterion, which is whether you can change what some instructions do, without redesigning the layout of the CPU.
Both ROMs and PLAs have a regular array structure, where you can change the stored bits with some minor changes in one of the masks, without having to make any changes in the layout of the CPU.
So the most useful definition of whether an instruction is micro-programmed or hard-wired is whether the method of changing what it does is by changing just the values of some bits in a table or by redesigning some CPU part.
This is the right definition from the point of view of the CPU designer.
Application programmers tend to partition the instructions of the modern CPUs in hard-wired and micro-programmed based on whether they execute in a single clock cycle or in multiple clock cycles, but in old CPUs it was quite frequent to have hard-wired instructions that executed in multiple cycles. Modern CPUs have much more available resources, so now it is normal for any hard-wired instruction to also be a single-cycle instruction, but there is no logical necessity for this.
An extra complication in many modern CPUs is that even if most instructions are usually hard-wired, there are also means to intercept the decoding for any opcode and replace the hard-wired operation with a micro-program, in order to be able to correct any dangerous bugs.
Microcoding is when the internal control structure of the processor operates in much the same way as the outer machine language program is processed. The microcode is a sequence of instructions stored in a memory (usually ROM, but can be EPROM or RAM), there is a microcode-program-counter, and the "microcontroller" functions by fetching "microcode instructions" one after another from the memory addressed by the microcode-program-counter.
The results of those fetched microcode instructions then control the actual CPU internal hardware elements. And depending on the type of microcode (horizontal or vertical) those microcode instruction's bits either directly control the hardware elements, or get further decoded to then control the hardware elements.
A good 10k foot description is "a mini-cpu controlling the hardware - that mini-cpu controlled by the outside visible machine language instructions"
It's a bit fuzzy and I don't think there's a single universally agreed on line. See the discussion in the "Microcode in RISC?" section of Ken's analysis of the ARM1 at http://www.righto.com/2016/02/reverse-engineering-arm1-proce... -- Ken thinks that it makes sense to think of it as microcode or perhaps hybrid/partially microcoded, but the designers of this CPU didn't think of it like that and viewed it as a non-microcoded design...
As far as I'm concerned it's bad terminology. Microcode to me at least means the processor trapping and emulating some edge case or similar, so I nearly always say decode to micro-ops whenever I can instead.
If you look at a die shot of the 6502, for example, you will see an area that looks confusingly similar to where microcode would be stored. Turns out, this is a PLA, not a microcode store. The best quick intro to microcoding that I have encountered is https://people.cs.clemson.edu/~mark/uprog.html.