I think the core question is whether hardware-accelerated translation could be meaningfully faster than software like Rosetta 2/Prism while avoiding the full dual-ISA complexity you're describing. Rather than literally implementing both instruction sets, it might be more like an ARM chip with specialized translation units and the extended ISA features you mentioned (memory ordering, etc.).

Intel's unique position with x86 IP could make this feasible where others can't, but whether the engineering effort is worth it for what might be a short-term market advantage is debatable.

Fujitsu and Nvidia also implement (at least) TSO.

https://threedots.ovh/blog/2021/02/cpus-with-sequential-cons...

I wonder if ARM instructions could be translated to Intel’s uOps. Then everything except that translation could be shared. And, since programs consist entirely of one type of instruction for the most part, we could imagine that the chip should be able to stick to just doing one type of translation for the duration of a program run, rather than having to figure it out for each instruction.

I’m not saying I want this, but it might be surprisingly not totally impractical.

A chunk of what you'd want (x86 alu flag generation) seems to be an extension that is incompatible with most of the arm architectural licenses which don't allow for custom extensions to user visible space. Apple is special here for reasons that probably aren't replicable.

> I don't understand what the difference is between "an ARM chip with native x86 translation" and a dual-ISA x86 and ARM chip.

Look at Apple's Rosetta 2 for an example. M-series Apple Silicon has special undocumented modes that mirror x86 architectural quirks that don't usually exist in ARM, in order to support AOT-translated machine code. The chip doesn't support x86 instructions, but it has the amenities to support x86 code. That could be what "native x86 translation" meant?