A few months ago, Intel gave up on trying to get Atom processors into the smallest of devices, after years of trying to achieve widespread success. Meanwhile, ARM processors have been getting more and more capable without giving up the power efficiency Intel apparently never came close to maintaining.
At this point, with an Apple interested in creating MacBook-style, er, MacBooks, it’s only a question of time until there will one day be a MacBook that can run non-x86/x86-64 applications. Instead of trying to predict when, I’m interested in figuring out “how”?
Bitcode. Although it would be more cumbersome and require introducing this technology to macOS, being able to recompile applications to a new target architecture is already mostly a solved problem and would finally give anyone a good reason to use the Mac App Store – giving you compatible versions without requiring developers to recompile their apps. Naturally, all of Apple’s own stuff would be Universal for x86-64 and 64-bit ARM, and naturally every developer could make their own apps Universal.
A double chip solution. Some parts of this would require some heroic engineering, like being able to have an operating system span, straddle or move across from one CPU to the other, but the potential to run the apps that are available in ARM versions on a separate ARM chip and let the x86 processor nap for a lot longer is irresistible.
Apple already makes a video adapter and a remote with ARM chips, and a beefier ARM chip could subsume some of the ancillary tasks that require separate chips today and possibly pay its weight in both board location and power budget even before we get to running apps.
The OS would likely run handily on ARM, and with the decade long effort to spread out tasks into isolated processes, running them on the most appropriate processor would suddenly be viable.
Rosett-me-not. Survivors of the 2006 Mac PowerPC to Intel transition may remember Rosetta, the dynamic binary translator that made it possible to run PowerPC apps mostly transparently and with some caveats. Survivors of the 1994 Mac 68k to PowerPC transition may remember the 68k emulator layer that was more capable and so efficient that when the Mac OS X strategy was first presented in 1998, a major point was made of how it was all finally going to be PowerPC native – the emulator had worked so well that parts of the OS had simply never been rewritten.
What this tells us is that the relative strengths of the architectures involved plays a role in the viability of providing emulation in the first place. Maybe by the time Apple cuts over, the ARM processor will be sufficiently able to emulate or translate the x86 instruction set at usable speeds for the intended devices, but I’m betting against that. For one thing, I think that ARM isn’t more energy efficient because of pixie dust but because of an instruction set that more easily lends itself to being implemented in an energy efficient way. Asking it to emulate the x86 instruction set has the air of snatching defeat from the jaws of victory, no matter how desirable being able to execute x86 instructions may be.
The Apple instruction set. Continuing from the previous points, one of the reasons that ARM has been able to progress is that it has been able to introduce new instruction sets and set a new cadence for compilers and other tools. You can continue to use the instructions you already use, or you can switch to these new ones and not only speed things up but save energy. One of the big ways power is saved in new processors is by shutting parts of the chip down when work isn’t happening. Apple’s “don’t call it PA Semi” department, led by Johny Srouji are becoming experts in making improvements to ARM designs and are surely keeping track of what an even more ideal processor would look like. Who’s to say that what I’ve been referring to as ARM won’t instead be a processor that works much more like ARM than x86, but which has new fundamentals and a new instruction set in addition to the ARM instruction sets (and may not even be backwards compatible with much of ARM at all)? I call it AppleArch and am hoping for a repeat of the reasonably correct forecasting of
End note: I am pulling all of this completely out of my ass, and many are the subjects where I know only just enough to be dangerous, like following the unveiling of the Mill with equal interest and befuddlement. Treat me like an authority on your own peril. That said, it all seems to make sense to me.