[snvzz]

>Of course, bot x86 and Arm started like that as well - but after 20+ years of evolution, they have to drag along a lot of history. (and one never really takes things away from an ISA, you only add new features, and at best deprecate old ones).

Feature-wise, RISC-V is already about on par and has managed not to become a mess.

Furthermore, unlike x86, ARM has broken binary compatibility several times in the past, and yet failed to use the chance to do anything else than minor adjustments.

RISC-V is in a really good position.

[chungy]

Pretty sure ARM has never broken binary compatibility, even across ISA expansions (16→32 bit, 32→64 bit).

[brucehoult]

ARM has broken binary compatibility many many times.

The first was probably when they took the condition codes out of the hi bits of the PC into their own register, to allow 32 bit addressing instead of 26 bit addressing, thus nuking all the software that thought (as it was encouraged to!) that saving and restoring the PC also saved and restored condition codes.

After Thumb mode was introduced they've waffled over whether you must use only BX to change modes, or whether any instruction that writes to PC (mov, add, pop ...) is ok.

Thumb only CPUs such as Cortex M3/M4/M7 can't run code from e.g. ARM7TDMI. The Thumb mode stuff will work, but it's not a complete ISA. On ARM7TDMI you have to switch to ARM mode for many things, while on ARMv7 you need additional instructions that don't exist on ARM7TDMI. CM0 adds only the essential operations to Thumb1, while M3/M4/M7 add basically a complete re-encoding of ARM mode -- minus conditional execution on every instruction.

In Thumb mode on ARM7DTMI (and successors) a 4 byte `BL` instruction is actually two 2-byte instructions run one after the other. You can separate them with arbitrary other instructions between them, as long as LR is not touched. In ARMv7 `BL` looks the same, but you can no longer split the two 2-byte halves -- it is now actually a 4-byte instruction, and other 4-byte instructions exist using the same initial 2 bytes.

And of course Aarch64 is utterly incompatible with any of the 32 bit ISAs. Early 64 bit cores from ARM also ran 32 bit code. At first they could boot 32 bit OSes, then only 64 bit OSes but they could run 32 bit user code. The latest ARM cores run only 64 bit code, and ARM has said no future 64 bit cores will run 32 bit code at all. Other 64 bit only cores also exist, including the ThunderX (9 years ago!) and Apple's M1 and M2 as well as all iPhones starting from the iPhone 8.

[sweetjuly]

ARMv8 aarch32 is backwards compatible with v5-v7 but aarch64 mode cannot run aarch32 code of any kind. ARMv8 makes supporting aarch32 mode optional too and so it really is a hard break.

[astrange]

ARMv8 AArch64 is pretty different from earlier ARMs and is probably more performant than the overly academic RISC-V.