That's the biggest difference with x86 and ARM, ARM got a lot of breaking changes with their versions, while x86 don't (I'm not sure if there was any breaking change in the las 20 years at least).
That's the biggest difference with x86 and ARM, ARM got a lot of breaking changes with their versions, while x86 don't (I'm not sure if there was any breaking change in the las 20 years at least).
Aren't those legacy instructions already emulated in microcode? I don't think they take up much physical footprint.
[0] Let me stop you right there before you suggest I recompile 15 years of operating systems, third party toolchains, and internal tools for ARM and then rebuild every intermediate container just so we can work around Rosetta shipping without necessary features. I know that you can ship a whole parallel stack of containers with ARM but that's not feasible in the slightest for anything but the most trivial use cases or entirely greenfield projects.
For work, I still have some third-party toolchains that were originally compiled on x86_64 linux in 2012. They are dockerized these days to make running these legacy toolchains easy. There is no possibility to recompile these on ARM to provide parallel containers that are compatible with Docker for Mac.
If x86 could get rid of the x86 instruction set and compile directly to something similar to uOPs, then some power reduction use and core area reduction could be achieved, but tooling cost would be immense.
I guess it should be slower too?
If TSO didn’t have a performance penalty, it wouldn’t need to be a separate mode. Also, it should be obvious that stricter ordering constraints inherently allow less parallelism, so lower performance.
If it were as simple as "they are the same once everything is decoded", then you'd expect a pre-decoded and pre-optimized program to be at least as fast, but it's not.