[snvzz]

Micro-ops are a microarchitecture implementation detail. They are also used by many RISC microarchitectures, and are ultimately irrelevant to ISA.

Ever since the RISC paper, every new architecture of any remaining significance today has been RISC. Today, it makes more sense than ever[0].

The only CISC that remains in large-scale use is x86, which I expect to finally be deprecated during this decade.

0. https://itnext.io/risc-vs-cisc-microprocessor-philosophy-in-...

[arcticbull]

My point was more that 'RISC vs CISC' is not a useful way to compare two processors. In the same way CISC CPUs break down instructions into a series of micro-ops, RISC CPUs (like the RISC-V) fuse instructions into macro-ops. Yes the ISA is different and yes that imposes some constraints on the design but it's not a particularly useful way of comparing two processors.

Ok CISC ISAs are out of favor today, although I suspect as some of these RISC ISAs age, they'll accrete instructions. The ARM ISA sure is a lot chonkier than it used to be. Modern ARM CPUs have a massive micro-op cache just like x86 CPUs do. I wouldn't be surprised if we wake up one day and it's half way to x86.

In my opinion ISA isn't relevant or interesting. [1]

I echo the sentiments in this article:

> In short, there’s no meaningful difference between RISC/ARM and CISC/x86 as far as performance is concerned. What matters is keeping the core fed, and fed with the right data which puts focus on cache design, branch prediction, prefetching, and a variety of cool tricks like predicting whether a load can execute before a store to an unknown address.

So to your point that:

> Today, [RISC] makes more sense than ever.

I would respond, today, it makes less difference than ever.

What actually happens under the hood of a modern performance-optimized CPU is so far removed from the ISA that the ISA is just a design curiosity.

'RISC architecture' isn't going to 'change everything' - how it's implemented: advances in branch prediction, prefetching, etc - that's going to continue to iteratively improve processors. The number of instructions is truly not a factor of note.

Does it never matter? Probably sometimes. Once in a while in some very specific applications - like pico-amp scale microcontrollers - it might? But for anything you’re thinking of it’s super irrelevant.

[1] https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-...

[snvzz]

>My point was more that 'RISC vs CISC' is not a useful way to compare two processors.

It isn't. Instead, it is a way to compare ISAs. And RISC is the way to go, because we've known for some 40+ years that CISC is bad.

>In my opinion ISA isn't relevant or interesting.

Except when it is.

One example: x86 is too complex to be reasoned with, so it's not an option where high assurance (and thus formal proofs) is a necessity.

>What matters is keeping the core fed, and fed with the right data which puts focus on cache design, branch prediction, prefetching, and a variety of cool tricks...

Another example: ARMv8 and v9 have horrendous code density. As a result, L1 needs to be larger to fit the same amount of code. Which means lower frequency. larger area and higher power usage. Similarly, a microcontroller's ROM would have to be larger to fit the same program, also bad.

>RISC CPUs (like the RISC-V) fuse instructions into macro-ops.

Not really. Fusion is mostly academic, rather than an industry standard. E.g. no RISC-V processor in the market does fusion[0].

>I would respond, today, it (RISC) makes less difference than ever.

For most applications, end users don't know or care what ISA is in there.

But, for anyone actually designing systems, it does matter. Complexity breeds bugs. Most bugs are security bugs. x86's (the one CISC that still sees chips fabbed, large scale) complexity is insane. And security thus impossible; a losing proposition.

In the present hyper-networked world, this is unacceptable. In IoT, using x86 should be criminal negligence, and we will no doubt see it actually recognized as such in the courts at some point in the not-so-distant future.

x86 had a good run. It's already well past the time to move on, leave it in the past where it belongs.

0. https://news.ycombinator.com/item?id=32614034

[arcticbull]

These are all great opinions that are countered soundly by the article I linked. Do you have articles you suggest I read?

> And RISC is the way to go, because we've known for some 40+ years that CISC is bad.

Quantify 'bad'. Again these are all opinions.

Nobody will argue with you x86 is terrible. What I'm saying, backed by the article I linked, is that the fact the x86 ISA is terrible really doesn't hold it back. And once you start optimizing a RISC architecture, over time, for performance, it quickly approaches the same thing.

> Not really. Fusion is mostly academic, rather than an industry standard. E.g. no RISC-V processor in the market does fusion[0].

It doesn't depend on fusion but since 2016 it's pretty clear it'll be an optimization. A big one! Which means that complexity is coming whether or not any market cores implement it today or not, which is part of the argument I'm making haha. Once you take the path of these optimizations, the cores start to look pretty familiar. Read the reply to the comment you linked.

Nobody is going to leave performance on the table to satisfy some niche opinions on complexity being bad.

> But, for anyone actually designing systems, it does matter.

What is "actually designing systems" today? There's complexity in everything (especially anything performant) and frankly, that complexity is abstracted effectively by compilers and operating systems.

> In the present hyper-networked world, this is unacceptable. In IoT, using x86 should be criminal negligence, and we will no doubt see it actually recognized as such in the courts at some point in the not-so-distant future.

Citation needed?

> x86 had a good run. It's already well past the time to move on, leave it in the past where it belongs.

Fine, but not relevant to CISC vs RISC.