feature article
Subscribe Now

Apple Hints at CPU and OS Independence

New Bitcode Format Could Be the First Step Toward CPU-Neutral Platforms

ARM, x86, or Apple? That question may make a lot more sense in a few months.

In amongst all the many things that Apple rolled out at its latest Worldwide Developers’ Conference (WWDC) in San Francisco was an almost-offhand mention of something called Bitcode. The company didn’t provide a lot of detail and, in fact, seemed to curtail some of its planned discussions just days before the event, but, from outward appearances, Bitcode lays the groundwork for a future filled with CPU-neutral Apple devices.

In other words, Apple may be getting ready to swap out ARM for x86, or vice versa.

Here’s what we know. Bitcode is a software-distribution format – a way to encode applications in a way that’s not entirely CPU-specific. That is, it’s an intermediate form of software, not quite binary but certainly not source code. It’s a bit like the intermediate object code that compilers spit out before all the pieces are linked together into an executable, but more generic than that. Specifically, Bitcode is neither ARM- nor x86-specific. A single Bitcode app could theoretically run on either processor.

So is this just another virtual machine? Like a different take on Java, but without the hype and the disappointment? Not really. While Java and other JVMs do store their apps in an intermediate format (“bytecode” in the Java vernacular), those apps then run on an imaginary processor architecture that’s simulated by the virtual machine. So Java apps never really ever get converted to “real” binary programs. They’re interpreted by the JVM, usually on the fly at runtime, sort of like BASIC and other interpreted languages.

Apple’s Bitcode retains the intermediate, CPU-neutral storage format, but only until you download the app from Apple’s App Store. At that point, the program gets converted to native binaries for your device. The iDevice to which the app is downloaded still runs native binary code. There’s no on-the-fly translation and no virtual machine. Thus, apps should run at native speed, not the obscenely retarded pace of interpreted Java bytecode. There’s also no JVM emulation to worry about. Bitcode – in theory, at least – is compiled for a real machine, such as an iPad, an iPhone, or a Mac. So Bitcode abstracts away only the distribution format, not the entire machine.

Bitcode isn’t quite the same as binary translation, where programs are converted from one CPU’s instruction set to another’s. That’s a whole different can of worms, and it is very rarely successful. Although – it must be said, Apple is one of the few companies to successfully pull this off – twice – when it switched from Motorola 68K processors to PowerPC, and again when switching from PowerPC to x86. Digital Equipment Corporation (DEC; RIP) and IBM have both deployed workable binary-translation schemes, too. But the number of oh-so-close failures far outnumbers the few successes. Binary translation always seems like such a good idea at the beginning, but all the evidence indicates that it’s fiendishly difficult in practice.

So… if it’s not a virtual machine and it’s not binary translation, what is Bitcode and why would Apple spend the time to create it?

For starters, it would allow the company to play fast and loose with its CPU architectures. Today, all iDevices run the ARM processor and all Macs use x86 chips. Relatively few apps are intended for both platforms, but, when they are, they have to be compiled separately – once for the x86 architecture running MacOS, and again for iOS running on ARM. Bitcode could make that distinction moot. Compile your app once, upload it to Apple’s servers, and let the App Store make the last-minute adjustments to CPU and/or operating system. Suddenly any app can run on any Apple system, regardless of the hardware or software inside. (It’s far from a slam-dunk, since you’d still want to make sure you app actually worked on both platforms, but Bitcode is the enabling technology.)

That allows Apple to change its hardware without disrupting the third-party software base. And – let’s face it – it’s the third-party apps and accessories that make Apple devices attractive. Apple needs to leverage that advantage while also giving itself the leeway to create new hardware. If every Mac has to use an x86 chip and every iDevice has to use an ARM chip, the company is doomed to maintain a two-headed product line forever. How much simpler things would be if Macs could run ARM chips and iDevices could use x86 chips – or if either product family could use custom Apple processors.

What’s that? A third CPU family? Why not – Bitcode lays the groundwork for exactly that.

Apple is one of the few ARM licensees to hold the valuable “architectural license” to the ARM architecture. That expensive contract allows Apple to design its own ARM processors from scratch, not just plunk down the premade Cortex A-99 designs handed over from Cambridge. And Apple employs quite a few accomplished CPU designers. And the company didn’t take out that rare architectural license by accident. And the development of Bitcode is not a coincidence. Apple is clearly embarking on a path of CPU and/or OS independence.

Of course, Bitcode could also serve less ambitious goals. It would facilitate the switch from 32-bit ARM chips to 64-bit chips, for example. Again, you’d compile and sell one app, but the App Store would tweak it at download-time for the appropriate target hardware. Bitcode could also abstract away coprocessors and other hardware accelerators. Just as with floating-point coprocessors in the 1990s, an app could be compiled assuming that a certain hardware resource was always present, but the App Store could replace hardware-dependent functions with their software equivalents.

Finally, Bitcode allows Apple to strip out functions that aren’t supported by the target device. For example, a single app compiled for iPad, iPod, and iPhone will necessarily include code that two out of three of those devices won’t support. Rather than download useless code (which takes up space on the user’s device), why not strip out the bits that won’t be used? Just as OS calls and shared libraries allow apps to avoid unnecessary duplication, Bitcode could streamline apps of redundant functions.

Bitcode also allows Apple to make fairly drastic changes to its devices, while still allowing apps (some of them, anyway) to function. The Apple Watch, for instance, is so new and untried that both developers and users (and Apple itself, one suspects) are trying to figure out what it’s good for. That creates some hesitation in the market – never a good thing. By offering a sort of bridge between Watch apps, iPad apps, and other apps, Apple makes coding for the Watch (and whatever comes next) a bit less scary and risky. If the next-generation Watch has radically different hardware and software resources, Bitcode can help last year’s apps get over the hump.

More cynically, Bitcode may also allow Apple to insert its own software into third-party apps. Certain OS calls could be replaced with functional equivalents that include tracking data, ad banners, malware, anti-malware, or anything else you care to imagine. Not likely, but possible.

In the end, Bitcode enables all sorts of hardware and software changes, both large and small, trivial and massive. It’s safe to assume that the first instances of Bitcode in the wild will be minor and unimpressive, and totally invisible to the end user. That’s Apple’s way: it’s all about the user experience, and developers will just have to keep up. Bitcode makes keeping up with Apple a bit easier, while also giving the Cupertino company some added flexibility in its hardware designs, processor choices, operating system APIs, and software distribution. Regardless of the initial implementations, Apple is playing a long game.

Leave a Reply

featured blogs
Dec 4, 2020
As consumers, wireless technology is often taken for granted. How difficult would everyday life be without it? Can I open my garage door today? How do I turn on my Smart TV? Where are my social networks? Most of our daily wireless connections – from Wi-Fi and Bluetooth ...
Dec 4, 2020
I hear Percepio will be introducing the latest version of their Tracealyzer and their new DevAlert IoT device monitoring and remote diagnostics solution....
Dec 4, 2020
[From the last episode: We looked at an IoT example involving fleets of semi-trailers.] We'€™re now going to look at energy and how electronics fit into the overall global energy story. Whether it'€™s about saving money on electricity at home, making data centers more eff...
Dec 4, 2020
A few weeks ago, there was a webinar about designing 3D-ICs with Innovus Implementation. Although it was not the topic of the webinar, I should point out that if your die is more custom/analog, then... [[ Click on the title to access the full blog on the Cadence Community si...

featured video

Improve SoC-Level Verification Efficiency by Up to 10X

Sponsored by Cadence Design Systems

Chip-level testbench creation, multi-IP and CPU traffic generation, performance bottleneck identification, and data and cache-coherency verification all lack automation. The effort required to complete these tasks is error prone and time consuming. Discover how the Cadence® System VIP tool suite works seamlessly with its simulation, emulation, and prototyping engines to automate chip-level verification and improve efficiency by ten times over existing manual processes.

Click here for more information about System VIP

featured paper

Reducing Radiated EMI

Sponsored by Maxim Integrated

This application note explains how to reduce the radiated EMI emission in the MAX38643 nanopower buck converter. It also explains the sources of EMI noise, and provides a few simple methods to reduce the radiated EMI and make the MAX38643 buck converter compliant to the CISPR32 standard Class B limit.

Click here to download the whitepaper

Featured Chalk Talk

Maxim's Himalaya uSLIC Portfolio

Sponsored by Mouser Electronics and Maxim Integrated

With form factors continuing to shrink, most engineers are working hard to reduce the number of discrete components in their designs. Power supplies, in particular, are problematic - often requiring a number of large components. In this episode of Chalk Talk, Amelia Dalton chats with John Woodward of Maxim Integrated about how power modules can save board space, improve performance, and help reliability.

Click here for more information about Maxim Integrated Himalaya uSLIC™ MAXM1546x Step-Down Power Modules