Comparing a Risc and a Cisc with Similar Hardware Organization (1991)

Interesting. Got a source for that?

I wonder if anyone has actually measured what the code size savings from this look like for typical programs, that would be an interesting read. RISC trope is to expose a "link register" and expect the programmer to manage storage for a return address, but if call/ret manage this for you auto-magically you're at least saving some space whenever dealing with non-leaf functions.

The original intent of uops in x86 was to break more complex instructions down into more simple instructions so the main pipeline wasn't super-variable.

If you look at new designs like M-series (or even x86 designs), they try very hard to ensure each instruction/uop retires in a uniform number of cycles (I've read[0] that even some division is done in just two cycles) to keep the pipeline busy and reduce the amount of timings that have to be tracked through the system. There are certainly instructions that take multiple cycles, but those are going to take the longer secondary pipelines and if there is a hard dependency, they will cause bubbles and stalls.

  > Highly unconstrained extensibility. While this is a goal of RISC-V, it is also a recipe for a fragmented, incompatible ecosystem and will have to be managed with extreme care.

For example, Intel can brand their own chips as RISC-V-ZIntelx8664, if they want to, because RISC-V-Zxxx implementation can be as incompatible with any other RISC-V implementations (and even specification) as one wants.

Meanwhile arm licensees shipped twenty-nine billion chips. Most with four cores, and some with many more.

Riscv is on the way up, but any death sentence for arm is decades away.

The main reason for that is that x86 code, outside of being register poor leading to lots of stack etc. use, decomposes most "ciscy" operations into LEA (inlined in pipeline) + memory access + actual operation.

VAX (and to lesser extent, m68k and others) had multiple indirections just to get the operands right, way more than what is essentially single LEA instruction. The most complex VAX instructions could have been ignored as "this is super slow one and rarely used", but the burden of handling the indirections remain, including possible huge memory latency costs.

M1 core is 2.28mm2 and Zen3 core is 4.05mm2 if you count all the core-specific stuff (and 3.09mm2 even if you exclude the power regulation and the L2 cache that only this core can use). That is 27-45% larger for generally worse performance (and all-around worse performance if per-core power is constrained to something realistic). I'd also note that Oryon and C1-Ultra seem to be much more area efficient than more recent Apple cores.

We're at a point where Apple's E-cores are getting close to Zen or Cove cores in IPC while using just 0.6w at 2.6GHz.

If you count EVERYTHING outside of the core (power, matrix co-processor, last-level-cache, share logic, etc), and average out, we get 15.555mm2 / 4 = 3.89mm2 for M1.

If we do the same for Zen3 (excluding tests and infinity fabric), we have 67.85mm2 / 8 = 8.49mm2.

M1 has 12mb of last-level cache (coherent) or 3mb per core while Zen3 has 4mb of coherent L1 and 32mb of victim cache (used to buffer IO/RAM read/write and to hold cache misses in hopes that they can be used eventually). You can analyze this how you would like, but M1's cache design is more efficient and gives a higher hit rate despite being smaller. Chips and Cheese has an interesting writeup of this as applied to Golden Cove.

https://semianalysis.com/2022/06/10/apple-m2-die-shot-and-ar...

https://x.com/Locuza_/status/1538696558920736769

https://semianalysis.com/2022/06/17/amd-to-infinity-and-beyo...

https://chipsandcheese.com/p/going-armchair-quarterback-on-g...

ARM shed 75% of their decoder size when removing support for the 32-bit ISA in their A-series cores and it’s nowhere near as bad as x86.

A Haskell analysis showed that integer workloads (the most common in normal computing) saw some 4.8w out of 22.1w dedicated to the decoder. That’s 22% of total power. Even if you say that’s the high-water mark and it’s usually half of that, it’s still a massive consideration.

If the decoder power and size weren’t an issue, they’d have moved past 4-wide decode years ago. Instead, golden cove only recently went 6 wide and power consumption went through the roof. Meanwhile, AMD went with a ludicrously complex double 4-wide decoder setup that limits throughput under some circumstances and creates all kinds of headaches and hazards that must be dealt with.

Nobody would do this unless the cost of scaling x86 decided was immense. Instead, they’d just slap on another decoder like ARM or RISC-V does.

x86 and z/Arch instructions for move/ALU/jmp/conditional branch are fine. They are not hard to decode and they are not hard to execute. That's the core of the µop instruction set (just encoded differently). Then they add some specialty stuff necessary to implement more complex instructions using sequences of µops -- and of course the SIMD stuff. That's it. It's a simpler version of the external ISA, NOT a RISC.

Part of the path the µops take is wide, possibly with the option of a shared field for a large immediate.

Instructions that map to short, fixed-length µops sequences are handled directly by the decoders that spit out a wide chunk of µops. Longer or variable-length µops are handled by having the decoders emit an index into a ROM of wide µops chunks. The decoders can often spit out both the first wide chunks AND the index (so there's no need to wait a cycle for the ROM to emit µops).

Multi-cycle µops are not much of problem, as long as the cycle count is predictable, preferably statically predictable. It is common to have µops that are "multi-issue", for example if they involve memory operands.