Waffle is a weblog.
The author of Waffle, some guy in Sweden, also occasionally writes stmts.net.

At ARM’s Length

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 xlangSwift.

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.


  1. I’ve thought about this quite a bit. I suspect that using Rosetta wouldn’t work well running CISC code on a RISC processor. It would take a RISC processor several cycles to run one CISC instruction. The 68k to PPC emulator worked because the PPC chips were dramatically faster than the 68k chips. That masked the performance hit from the user, which is why the emulator appeared to work so well. These ARM chips would likely be a lot slower than the x86 processors that they’d be replacing.

    That’s why I think the dual processor (one ARM, one x86) is more likely, at least for the time being. I wouldn’t be surprised if certain models went ARM only sooner, such as the 12″ MacBook, while the MacBook Pro would likely have both chips for a while to maintain compatibility and performance running pro apps.

    In both cases, having both ARM and x86 frameworks on disk would balloon the storage footprint of the OS at a time when smaller SSD storage is becoming the norm. When Rosetta was removed with Lion the OS got smaller. That’s also the first OS release that wasn’t shipped on DVD.

    I think your Apple instruction set idea is interesting and seems like something Apple would do.

    By D · 2016.07.14 18:33

  2. I completely forgot about the RISC/CISC split, but either type simulating the other is going to have an uphill battle. That said, both Rosetta and the 68k emulator did cross the cliff… which is why I think the relative strengths are also important. But of course the PowerPC didn’t have to worry as much as ARM would about having to keep the energy consumption down in doing its emulation.

    Ballooning storage footprint is very interesting, as is in-memory. Having two chips, who knows how RAM is solved and what the tradeoffs are depending on varying load. I don’t think the storage footprint will be larger enough to be really intrusive, especially with the drive to make people want to page out to iCloud, but it would hit the computers where it’s the biggest problem first!

    The more I think about it, maybe even with all the trouble this brings, they may be more likely to just ship it with only ARM (possibly + automatic ARM bitcode recompilation for App Store apps) and tell people to tough it out.

    By Jesper · 2016.07.15 22:01

  3. Well hello there

    By Phil Nelson · 2016.07.21 18:45

  4. @Phil: o hai

    By Jesper · 2016.07.27 17:21

Sorry, the comment form is closed at this time.