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.