Hmm. Random question here... what prevents Apple from building in an x86-to-uops decoder stage into their desktop ARM CPUs?
That way they could run old code simultaneously with new code - x86 apps get their memory flagged (by the MMU perhaps?) that all code from this memory region gets executed with the x86 decoder stage, and code in normal memory gets executed with the ARM decoder stage.
And to be honest this is entirely what I'm expecting of Apple - yes they are not concerned with backwards compatibility but no one is going to buy a multi-ten-thousands-dollars Mac Pro or even a multi-thousands MacBook Pro if it can't run Photoshop or their favorite sound editing/DJ suite.
ARMs have a more relaxed memory model than x86 so that would be a complication, though I suppose you could just have the decoder put barriers everywhere.
x86 is infamously hard to decode, though. Often you speed it up by tagging instruction boundaries in the L1$ which you wouldn't have in the Apple ARM devices by default. If you're willing to just decode one x86 instruction per cycle I suppose the overhead wouldn't be unreasonable.
Photoshop is already running on ARM—specifically, on Apple's A-series chips.[0]
Unless you're doing something at least moderately esoteric, if you have an actively-developed macOS application today, you'll be able to produce an ARM version of it tomorrow (or, y'know, whenever Apple actually activates this capability) by ticking the right box in Xcode.
There might very well be a compatibility layer available for a transition period (there was for 68k->PPC, Classic->OS X, and PPC->Intel), but that's not at all the same thing as saying Apple will build in hardware-level x86 support in perpetuity.
> if you have an actively-developed macOS application today, you'll be able to produce an ARM version of it tomorrow (or, y'know, whenever Apple actually activates this capability) by ticking the right box in Xcode.
Will this also take care of existing low level optimizations? I can easily imagine Adobe and everyone in the sound/3D area to run custom specific x86 Assembler code in hot paths.
I don't think that you necessarily have to have an x86-to-uops decoder: there is a Chinese MIPS clone which has additional instructions which helps a lot emulation such as 80bit FP operations, etc.
That way they could run old code simultaneously with new code - x86 apps get their memory flagged (by the MMU perhaps?) that all code from this memory region gets executed with the x86 decoder stage, and code in normal memory gets executed with the ARM decoder stage.
And to be honest this is entirely what I'm expecting of Apple - yes they are not concerned with backwards compatibility but no one is going to buy a multi-ten-thousands-dollars Mac Pro or even a multi-thousands MacBook Pro if it can't run Photoshop or their favorite sound editing/DJ suite.