[Symmetry]

Yes, the 80286 used microcode and so instruction took several cycles. That's what the article was gesturing at when it said "But another reason was that more complex instructions took longer for a chip to execute. By keeping them simple, you could make every instruction execute in a single clock cycle."

EDIT: Though later, in the Pentium era, x86 started to do simple instructions like `ADD AX, [BX]` without microcode.

[monocasa]

Eh, that's just an internal design decision. The ARM1 used microcode as well.

[jecel]

ARM1 had multicycle instructions (LDM and STM) and the ARM2 added more (MUL and MLA) but as far as I know these were controlled by hardwired finite state machines, not microcode.

[monocasa]

https://www.righto.com/2016/02/reverse-engineering-arm1-proc...

[jecel]

Thanks for the link. As Ken points out at the end, "Probably the biggest objection to calling the ARM1 microcoded is that the designers of the ARM chip didn't consider it that way.[4] Furber mentions that some commercial RISC processors use microcode, but doesn't apply that term to the ARM1". My opinion is the same as Steve Furber's, though I can certainly see Ken Sherriff's viewpoint.

In theory PLAs and ROMs are fully equivalent. In practice, while the ROM can accept any possible "microcode", a PLA might have to be enlarged if you want to change some of the "micro instruction". This need to change the hardware to change the functionality of an instruction is what makes me consider this design hardwired instead of microcoded.

[EDIT] Another issue is that the ARM1 has three pipeline stages. The "microcode" here is not used for the fetch and decode stages, only the execute one. So though register to register operations take 3 clock cycles to execute, only one "micro instruction" is needed (the second line in the table).

[monocasa]

> Thanks for the link. As Ken points out at the end, "Probably the biggest objection to calling the ARM1 microcoded is that the designers of the ARM chip didn't consider it that way.[4] Furber mentions that some commercial RISC processors use microcode, but doesn't apply that term to the ARM1". My opinion is the same as Steve Furber's, though I can certainly see Ken Sherriff's viewpoint.

So reading, the citation fully, it seems that Furber doesn't really dive deep into the ARM1, instead saving a deep dive for the ARM2 as well as an additional chapter about the changes then made for the ARM3. I think kens might be steel manning the position.

> In theory PLAs and ROMs are fully equivalent. In practice, while the ROM can accept any possible "microcode", a PLA might have to be enlarged if you want to change some of the "micro instruction". This need to change the hardware to change the functionality of an instruction is what makes me consider this design hardwired instead of microcoded.

Traditionally, the difference would be defined as whether or not it's structured as an address being decoded to create a one hot enable signal for a single row of the array at a time. When you take the FSM signals as a sub address, and the init, interrupt, and decoded instr bits as a segment address, this is what you see here. And that matches the structure seen in traditional CISC microcode ROMs.

Additionally, there is extra space on the die for an additional few rows.

> [EDIT] Another issue is that the ARM1 has three pipeline stages. The "microcode" here is not used for the fetch and decode stages, only the execute one. So though register to register operations take 3 clock cycles to execute, only one "micro instruction" is needed (the second line in the table).

The pipelining doesn't really matter here. The 486 for instance more or less completed one (simple) instruction a clock, but had a rather deep for the time piepline where those instructions would have several cycles of latency. Those simple instructions were also a single micro op despite being being processed in several pipeline stages. And the micro decode was not the first stage of the pipeline either. The 486 had a deeper pipeline with fetch, decode 1, decode 2, execute, and writeback pipeline stages, but didn't start emitting micro instructions except as the output of the third pipeline stage.

[jecel]

Very good points. About ARM1, 2 and 3, if my memory from 4 decades ago is correct then the changes from 1 to 2 were a move to a slightly newer process node, replacement of "multiply step" with actual multiply instructions and the addition of the co-processor interface. 2 and 3 are the same processor, but with the latter adding a 4KB onboard unified cache, which allowed it to run at a much higher clock frequency.