That's because there are only a few ISAs left standing. The ISA does have consequences for core design. This becomes apparent for ISAs that were unintentionally on the wrong side of the development of superscalar. The dead ISAs assumed in-order, single-issue, fixed-length pipelines and as soon as the state of the art shifted those ISAs became hard to implement. MIPS and SPARC are both basically incompatible with modern high-performance CPU design techniques.

> MIPS and SPARC are both basically incompatible with modern high-performance CPU design techniques.

I don't see how that follows at all? MIPS in fact is about as pure a "RISC" implementation as is possible to conceive[1], and it shares all its core ideas with RISC-V. You absolutely could make a deeply pipelined superscalar multi-core MIPS chip. SPARC has the hardware stack engine to worry about, but then modern CPUs have all moved to behind-the-scenes stack virtualization anyway.

No, CPUs are CPUs. Instruction set architectures are a vanishingly tiny subset of the design of these things. They just don't matter. They only seem to matter to programmers like us, because it's the only part we see.

[1] Branch delay slots and integer multiply instruction notwithstanding I guess.

The design of RISC-V starts with an entire chapter excoriating MIPS for being useless and impossible to reduce to transistors.

Some of the same people were involved, no? They must have had a good time writing that. “Things we have learned the hard way”.

And now MIPS, the company, makes RISC-V

Berkeley RISC I and RISC II had register windows, and led to SPARC. MIPS was Stanford.

And, yes, they learned the hard way that register windows are a bad idea. Patterson says they did it because their compiler didn't have as good register allocation as Stanford's compiler.

We had to touch MIPS in school. Having to deal with branch delay slots was cruel. It broke some of my classmates. We were on a cusp of needing every programmer we could get and they were torturing students. I hope those teachers lost sleep over that.

Am I correct in recalling they removed branch delay slots in a later iteration of the chips?

IIRC They made new branch instructions without delay slots, but the normal branch instructions still have delay slots.

Had to write MIPS assembly by hand recently, incredibly counter intuitive.

The decode with variable width instructions is one of the bottlenecks for ipc though. Its hard to imagine, for example, a 10-way decode on x86.

An internal fixed with encoding inside the instruction cache may work.

> Its hard to imagine, for example, a 10-way decode on x86.

Uh, why? Instructions start at byte boundaries. Say you want to decode an whole 64 byte cache line at once (probably 10-14 instructions on average). Thats... 64 parallel decode units. Seems extremely doable to me, given that "instruction decode" isn't even visible as a block on the enormous die shots anyway.

Obviously there's some cost there in terms of pipeline depth, but then again Sandy Bridge showed how to do caching at the uOp level to avoid that. Again, totally doable and a long-solved problem. The real reason that Intel doesn't do 10-wide decode is that it doesn't have 10 execution units to fill (itself because typical compiler-generated code can't exploit that kind of parallelism anyway).

That's a Zen 2 core: https://static.wixstatic.com/media/5017e5_bbd1e91507434d40bc...

Overlaid on a higher resolution die shot https://static.wixstatic.com/media/5017e5_982e0e47d7c04dd693...

Here's a POWER8 floorplan: https://cdn.wccftech.com/wp-content/uploads/2013/08/IBM-Powe... (The decoder is subsumed under IFU)

And POWER9 https://www.nextplatform.com/wp-content/uploads/2016/08/ibm-...

Didn't find any recent, reliable sources for Intel cores.

Why does the middle of the Zen FPU look like cache lines?

I believe those are the utterly massive register files needed to feed a modern vector FPU.

That would have been my guess. But I don’t think I’ve ever seen a register file big enough that I could spot it without a label. I’m almost surprised they are so tall and not wide. Or is that because I am looking at it sideways, and each register is top to bottom?

This is about Skylake rather than Zen2 but it's fascinating, if the subject of what's-really-in-a-register-file is fascinating to you: https://travisdowns.github.io/blog/2020/05/26/kreg2.html

When I still read architecture docs like novels, there was a group experimenting with processor-in-memory architectures. Where the demo was Memory chips doing vector processing of data in parallel.

I wonder how wide SIMD has to get before you treat it like a CPU embedded into cache memory.

Though I guess we are already looking at SIMD instructions wider than a cache line…

According to Agner Fog's manuals, the physical register file of a Zen 2 FPU contains 168 vector registers of 256 bits each. In total the vector registers hold 5 kB, so much less than the 32 kB L1 data cache, which isn't that large on the die image. Even if the middle of the FPU includes the register file, the regular structure must be mostly something else.

The register file allows much more accesses per cycle though and should actually be truly dual-ported (one register can be read and written in the same cycle). I'm not sure how exactly this works but Zen 2 has four vector units in the FPU so I'd naively expect the register file should be able to serve ~eight 256 bit reads per cycle and ~four 256 bit writes per cycle. So it should have those numbers of read and write ports at least? Additionally there should be a forwarding network around the ALUs. L1D only has a fraction of that connectivity. So between being dual-ported, having many more ports and probably the forwarding/bypass being integrated into this structure or at least being adjacent to it leads me to expect the FPU register file having a dramatically lower bit density than the L1D cache.

> The real myth is the idea of a CISC/RISC dichotomy in the first place

The divergence was one of philosophy, and had unexpected implications.

CISC was a “business as usual” evolution of the 1960s view (exception: Seymour Cray) that you should make it easy to write assembly code so have lots of addressing modes and subroutines (string ops, BCD, etc) in the instruction set.

RISC was realizing that software was good enough that compilers could do the heavy lifting and without all that junk hardware designers could spend their transistor budget more usefully.

That’s all well and good (I was convinced at the time, anyway) but the results have been amusing. For example some RISC experiments turn out to have painted their designs into dead ends (delay slots, visible register windows, etc) while the looseness of the CISC approach allowed more optimization to be done in the micromachine. I did not see that coming!

Agree on the point that the cores themselves have found a common local maximum.

But there wasn't ever a divergence in philosophy. It was a straight switch.

In the 70s, everyone designing an ISA was doing CISC. Then in the 80s, everyone suddenly switched to designing RISC ISAs, more or less overnight. There weren't any holdouts, nobody ever designed a new CISC ISA again.

The only reason why it might seem like there was a divergence is because some CPU microarchitecture designers were allowed to design new ISAs to meet their needs, while others were stuck having to design new microarchitecture for legacy CISC ISAs which were too entrenched to replace.

> For example some RISC experiments turn out to have painted their designs into dead ends

Which is kind of obvious in hindsight. The RISC philosophy somewhat encouraged exposing pipeline implementation details to the ISA, which is a great idea if you can design a fresh new ISA for each new CPU microarchitecture.

But those RISC ISAs became entrenched, and CPU microarchitecture found themselves having to design for what are now legacy RISC ISAs and work around implementation details that don't make sense anymore.

Really the divergence was fresh ISAs vs legacy ISAs.

> while the looseness of the CISC approach allowed more optimisation to be done in the micromachine.

I don't think this is actually an inherent advantage of CISC. It's simply result of the shear amount of R&D that AMD, Intel, and others poured into the problem of making fast microarchitectures for x86 CPUs.

If you threw the same amount of resources at any other legacy RISC ISA, you would probably get the same result.