My operating systems teacher 2001 was a total RISC fan and always said it would eventually overtake CISC.

I guess, he didn't expect this to take well after his retirement.

ARM today is probably more CISCy than what he considered CISC in 2001.

The best analysis of RISC vs CISC is John Mashey's classic Usenet comp.arch post, https://www.yarchive.net/comp/risc_definition.html

There he analyses existing RISC and CISC architectures, and counts various features of their instruction sets. They clearly fall into distinct camps.

But!

Back then (mid 1990s) x86 was the least CISCy CISC, and ARM was the least RISCy RISC.

However, Mashey's article was looking at arm32 which is relatively weird; arm64 is more like a conventional RISC.

So if anything, arm is more RISC now than it was in 2001.

amd64 is more RISC now than ia32 was in 2001 as well.

AArch64 is load-store + fixed-instruction-length, which is basically what "RISC" has come to mean in the modern day. X86 in 2001 was already… not that :)

I always understood it as that too.

Eh, it has a lot of instructions, but that was only the surface of RISC. It's a deeper design philosophy than that.

Also, isn't x86 ISA just a translation layer today? I thought on the metal, there is a RISC like architecture these days anyway.

Not really, because the variable length instructions have consequences - mostly good ones because they fit in memory better.

Also, the complex memory operands can be executed directly because you can add more ALUs inside the load/store unit. ARM also has more types of memory operands than a traditional RISC (which was just whatever MIPS did.)

I had the impression that M1 would outperform others because it didn't had variable length instructions.

Why do you think they have good conequences?

I've understood it, the tradeoff is

The upside to variable length instructions is that they are on average shorter so you can fit more into your limited cache and you make better use of your RAM bandwidth.

The downside is that your decoder gets way more complex. By having a simpler decoder Apple instead has more of them (8 wide decode) and a big reorder buffer to keep them filled.

Supposedly Apple solved the downside by simply throwing lots of cache at the problem and putting the RAM on-chip.

I'm not a CPU guy and this is what I've gathered from various discussions so I'm happy to be corrected.

In most cases, yes, but it doesn't get rid of the complexity for compiler backends that can't directly target the real instruction sets Intel uses and have to target the compatibility shim layer instead.