Notice that it's the only one remaining?

Yes, it's a weirdo.

Not defending the weirdo, but IBM Z is a thing that is shipping, heavily used, and still evolving. It's more CISC than even x86.

I do find it sad that we are stuck in an 80 year old paradigm that is a horrible fit for how CPUs are actually implemented in 2022, but the inertia is a strong in this one.

Inertia is the same as backward compatibility.

Kinda like gas engines and fuel pumps. Or wall socket formats. Inertia.

I think you are illustrating my point, thanks. Gas engines are surely but slowly being replaced with much better, cleaner, and more efficient alternatives. Wall socket formats are there to stay but increasingly low DC loads are coalescing around USB, with USB-C really accelerating the change.

So yes, we can overcome inertia, it just take a lot of energy.

ARM isn't a pure RISC anymore; it has complex addressing modes and arm7 has different instruction lengths. Complicated instructions are still worth adding if they happen to be hardware efficient, instruction fusing and cracking are expensive too and aren't optimization miracles.

I don't think RISC is a very useful term.

You mean as opposed to the other architectures mentioned in the article? ppc, mips, itanium and alpha. Two of which are utterly dead, one of which looks like it's dying (mips) and one that is little more than a niche product (ppc).

It seems that MIPS has almost been entirely relegated to the academic space for courses on processor architecture

Implying that so called RISC cpus are actually RISC. There is nothing even remotely "reduced" about a modern ARM cpu.

> Notice that it's the only one remaining?

Motorola 68K is still around too.

Came here to say that. At the time the post was written it was really just comparing x86 to the already dying RISC. Nowadays that comparison makes even less sense as the two schools of thought have more or less converged.

In essence, it is a RISC since the days of Pentium Pro. Each instruction is decoded to several micro-operations and the trick of making the CPU run fast lies in the decoder.

This also leads to situations where many instructions in x86 asm will run faster than fewer complex instructions which the decoder may not decode to its most optimal micro-operations sequence.

No, this take is incorrect. x86-64 instructions do get lowered into µops, but all the common ones will only execute one, or maybe two. The real win for µops is letting Intel microcode instructions that nobody cares about, but you really shouldn't be using them anyways.

To what extent is the decoding consistent? It always felt weird to me that we'd do something in hardware on every execution that could be done once in software at compile time. But if the decoder does smart things that would make more sense to me. For example, with SMT the decoder could choose not to use certain ops if the compute units are in use by the other thread.

That post isn't true, common instructions only take a few µops (or even one) and the main difference is register renaming. Microcoding mainly lets them support old and very complicated instructions that nobody actually needs to be fast.

You can see instruction latencies at https://www.agner.org/optimize/.

I am not sure of any arch that does this, but having a second stage decode buys 2 things off the top of my head - better instruction cache usage, esp. for small loops, and the flexibility to decode ops differently on different versions of the same arch from one binary. Otherwise you would have to have tons of different versions for each flavor of x86 out there.

Intel and AMD CPUs have micro op caches for tight loops.

> on every execution that could be done once in software at compile time

Which is to me, essentially, VLIW. Those architectures didn't work out very well. There's a lot of memory pressure just to move instructions around and the costs didn't seem to outweigh the benefits.

The Mill CPU and architecture is a fascinating approach here. Who knows if we'll ever see a real piece of hardware from them, but as I understand it they require a compiler tuned to the exact cpu model to maximize on-die memory and other aspects.

It is very inconsistent between major microarchitectural revisions, sometimes even between me minor steppings. Sometimes firmware updates can change the decoding (usually to fix bugs).

The firmware can only do this by turning on an extremely slow fallback path. It's not common and it's seen as an avenue of last resort.

That's an implementation detail. The submission was about architecture.