Another thing they can do: it allows them to introduce new non-ARM-standard ops and immediately recompile the app store to take advantage of them.

Every now and then I see a new comparison of the Swift/ObjC dispatch assembly. Now imagine — that could be a single opcode. Or the dispatch table could get pinned to a particular cache. Or it could be other micro-optimizations that they are in a unique position to exploit with full control of the language, compiler and chip.

I have no idea how feasible these things might be or how much of a gain it would create, but they can look through their corpus of LLVM-IR and identify hot-spots where a new opcode would speed everything up by some margin.

Good point, but remember Apple license the ARM architecture from ARM (the company), and they probably aren't allowed to deliberately ship partially-compliant ARM hardware.

Apple is much bigger than arm and could easily change the rules.

They may be smaller, but they have IP Apple needs now. Apple just can't do whatever it wants to just because it's big.

They could buy arm, or offer enough cash until they capitulate.

Since all modern CPUs have a ton of microcode, would it be hard to emulate the x86 when needed, and retain backwards compatibility like that?

Not particlarly; in fact, apple has basically done this exact thing twice in the past (https://en.wikipedia.org/wiki/Mac_68k_emulator), (https://en.wikipedia.org/wiki/Rosetta_(software).

But I believe we're (hypothetically) talking about ARM, not x86, code.

Aside: Apple's 68k-on-PowerPC emulator was an amazing piece of work. It didn't run 68k code in a separate environment; it allowed 68k code to run alongside PowerPC code, to nearly the same level of transparency. Applications could mix ISAs in libraries and code resources, and system extensions could patch PowerPC system functions using 68k code or vice versa. It was surprisingly efficient, too: the first PowerPC systems used system software consisting mostly of 68k code, and still ran faster than the native 68k systems they replaced.

I've never seen anything quite like it since. About the closest I've seen is the way that Thumb code can be integrated with native ARM code, and that's explicitly just a different instruction encoding, rather than a separate ISA.

A big part of the success with the 68k switch over was that the 68k line was getting long at the tooth. Clock for clock 601 would trounce 68040 (even the 486 was faster per clock). Plus the base 601 was at 60Mhz, while the fastest 040 based mac was 40Mhz (the quadra 840av, of which I picked up one a few years later for $40, and still have it).

So apple was working with something north of 3x the raw performance, its no wonder that most people with older macs that weren't anywhere near the performance of the 840AV thought the powermac was incredible.

The problem with that, at least in the case of Rosetta, is that the QuickTransit technology underlying it got bought by IBM and disappeared from the open market, so doing that trick again would be...a moderate time+cost sink.

Wiki for QuickTransit seems to think that a number of prominent people from Transitive hopped to ARM and Apple (which might be telling, given the claims of the original post), but has no citations.

Eh, JITs aren't the most complicated things on the planet. There's plenty of people who can do it outside of QuickTransit. Like, look inside most emulators.

Given that Apple is writing compilers and designing chips, on-the-fly recompilation shouldn't be a big problem for them.

> There are LLVM targets with corresponding ABIs that are nonspecific to architectures like PNaCL but Apple is not using them

They do indeed support LLVM IR target(s) that are, in fact, much more architecturally-nonspecific than PNaCl, namely the spir[64]-unknown-unknown target. See https://github.com/KhronosGroup/SPIR and /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/openclc (on a Mac, since 10.7).

I don't know if bitcode with this target triple is necessarily suitable for the Apple Watch, however.

SPIR is basically portable gpu assembly. I wouldn't count it as an architecturally-nonspecific target.

It's really not. It's barely an abstraction over LLVM IR

RISC-V is not that close to ARM, and it's not mature enough for Apple to move to it. RISC-V is interesting but I think we'll see it adopted in commercial embedded systems first.