There's another factor here: to have a low latency, the L1 cache has to be indexed by the bits which don't change when translating from virtual addresses to physical addresses. That makes it harder to have a larger low-latency L1 cache when the native page size is 4KiB (AMD/Intel) instead of 16KiB (Apple M1/M2).
That is, most of the "cleverness" allowing for a larger L1 instruction cache is simply a larger page size.
(also what do you believe happens with 4k pages on M1, since it does support those, or why did the A7 have larger caches than Zen4 a decade ago, which was well before 16k pages)
Also, x86 code is compact, but not as compact as in era of 8080 [2] - here addition and multiplication require 3 bytes each, 6 bytes total. To my surprise, ARM has an add-multiply instruction and it uses just 4 bytes (instead of 8) [3].
And RISC-V uses 6 bytes because of shortened instruction for addition [4]
Of course, this simple function cannot be a replacement for proper analysis, but it seems that x86 code is not significantly denser.
Also to my great disappoitment none of those CPUs has checked overflow for arithmetic operation.
[1] https://godbolt.org/z/jsoccE5jv
[2] https://godbolt.org/z/jTMs1MEzh
Aarch64 is roughly on par for encoding density.
What? I just wrote a simple main and a couple of small helper functions. How can we be past 20 kB of .text section?
Look at the demoscene for an example of dense x86 code, especially in the sub-1K categories. They routinely achieve code densities for x86 that no compilers I know of can get close to, and AFAIK I have not seen the same happen with ARM, nor MIPS or any other well-known RISC.
3-address instructions improve code density only in situations where both source operands are needed later.
Having had to patch binaries on multiple occasions by inserting instructions, it is definitely not hard to do so for x86 as one can easily find "slack" that the compiler left behind[1], but I once had to do it for a MIPS binary, and it was definitely not easy to squeeze in the few extra instructions I needed inline; I ended up having to detour to another area with jumps instead.
Here's an old paper where the authors tried to optimise for code density manually, and you can consistently see x86 beating ARM and MIPS:
https://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_den...
[1] See https://news.ycombinator.com/item?id=15720923 for an example.
Pyrit, a ray tracing demo in 256 bytes, does all of that: https://www.pouet.net/prod.php?which=78045
You probably wouldn't want your general purpose compiler doing this sort of thing! The resulting code would be suboptimal and fragile.
Yes - we're stuck with the historically convenient collection of operations and types. Our CPUs are amazingly fast but very little smarter than decades ago.
Backwards-compatibility pretty much locks us into the same logical space. At least when people were designing new and amazing computers using actual wire (!) they felt free to implement what they thought would be useful, not just copy the existing model.
While MIPS can trap on overflow, most architectures can at least set flags for conditional branch. PowerPC OR's the overflow flag into another flag, so you can choose to check that flag for overflow first after a block of calculations.
I really want Mill to become successful. It has "NaR" (Not A Result) - like NaN but for integers. For every arithmetic instruction, there is has a variant that can set NaR. Like a NaN it is carried through the data-flow, and there's a trap first when it reaches a store or conditional instruction.
Fused multiply-add is (https://en.m.wikipedia.org/wiki/Multiply%E2%80%93accumulate_...) is extremely useful and part of IEEE754-2008.
Because of that, it would surprise me if a modern CPU with floating point wouldn’t have it.
> And RISC-V uses 6 bytes because of shortened instruction for addition
That Wikipedia page claims RISC-V has fused multiply-add, so that may be compiler inefficiency. An answer to https://stackoverflow.com/questions/57248403/why-fused-multi... says gcc can generate it at -O3)
In fact, 64-bit ARM does not have a regular MUL instruction. "MUL" is an alias to a MADD with the zero register as addend.
Flipping one parameter bit in the instruction word changes a MADD into a MSUB. That instruction is used to compute the remainder after a division. Bigger ARM cores (such as Apple M1) perform macro-op fusion of DIV and MSUB to deliver both quotient and remainder in one operation.
Anyway. I thought that was pretty clever by ARM's designers.
It's unclear to me if they will pull ahead on the perf/area game with the era of 8-wide x86 decoders coming.
The problem is that x86 has a lot of legacy that wastes the potential gain of variable length encoding. If I remember correctly, the code density of 64-bit x86 isn't really significantly better than 64-bit ARM, despite ARM dropping support for Thumb.
RISC-V is going to be interesting in that regard because with the latest revisions of the compressed instruction format, it can potentially beat both ARM and x86 on real-world code density, while still being easier to decode.
This is true in theory but I question how much it applies to current CPUs. A problem I see is that the x86 instruction set was designed in the 1970s with corresponding assumptions about instruction frequency, speed of memory, number of CPU cycles, pipelining (or lack thereof), addressing modes, etc. Even if the variable-length encoding was close to optimal back then, there's no way it's remotely optimal given all the extensions to the instruction set, the change from hand-coded assembly to compiler-generated code, and many more seismic shifts in the ISA. So I think x86's variable-length instructions now have all the downsides of complicated decoding as well as the downsides of suboptimal code density. But you also can't reshuffle all the instructions and addressing modes without breaking backward compatibility.
The are ripple effects to consider as well. The large L1 caches of M1 (320 KB total) put capacity pressure on L2, towards larger sizes and/or away from inclusive policy. See the 12MB shared L2. Meanwhile, the narrower decode of Zen4 puts pressure on things like branch prediction accuracy & mispredict correction latency - if you predicted the wrong codepath, you can't catch up as quickly. See the large branch predictors on Zen4.