← Back to context

Comment by inkyoto

3 hours ago

Once again – respectfully – this remains largely twaddle as the facts themselves state otherwise.

Even at the microarchitecture level, the hard part is not raw CISC-ness but irregularity and compatibility baggage. In that respect x86 was usually the uglier customer.

High-end x86 implementations ultimately scaled further because Motorola had less market pressure and fewer resources than Intel to keep throwing silicon at the problem, not because m68k was somehow harder to optimise.

Later high-performance m68k cores did what later x86 cores also did: translate the architected variable-length instruction stream into a more regular internal form. Motorola’s own MC68060 manual says the variable-length M68000 instruction stream is internally decoded into a fixed-length representation and then dispatched to dual pipelined RISC execution engines. That is not evidence of an ISA that was uniquely resistant to microarchitectural optimisation. It is evidence that Motorola used the same broad trick that became standard elsewhere: hide ISA ugliness behind a cleaner internal machine.

There is also a deeper point. The m68k ISA was rich, but it was comparatively regular and systematic at the architectural level. The m68k manuals show a clean register model and – notably – consistent condition-code behaviour across instruction forms. That kind of regularity is exactly what tends to help both compiler backends and hardware decode/control design. By contrast, x86’s biggest hardware pain historically came not from being «less CISC» than m68k, but from being more irregular and more burdened by backward compatibility.

Lastly, but not least importantly, CPU's were not the core business of Motorola – it was a large communications-and-semiconductors company, with the CPU's being just one product family within a much larger semiconductor business.

There was no clear understanding within the company of the rising importance of CPU's (and computing in general), hence the chronic underinvestment in the CPU product line – m68k did not see the light of highly advanced, performant designs purely because of that.

Well, here I am following what people who worked on CPUs at the time wrote.

And from the point of microcoded system like x86 and 680xx were (including 68060) it is important to how many microinstructions your instruction stream will decode - something that greatly favours ISAs that are not orthogonal - and major reason why x86 often has 1.2-1.6 ratio of microinstruction to instruction for overall program code.

Orthogonality makes it problematic because while it's easy in "interpreter microprogram" style of old and easy to program in assembly for, it means that for example for 68k you have to deal with many addressing modes for every operand - whereas x86 pretty much fuses it between 1 to 2 instructions because only one operand can have any computed address, and scope of available computation is limited (even compared to just 68000).

This means that while both architectures can use "translation microcode" approach, one (x86) will easily decode into one or two 72bit instructions (using P6 here) with worst case involving somewhat rare 3 operand form of memory address (which still can only happen for one operand of the instruction, not both)

The non-technical parts I won't dispute.