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
Sep 19, 2023
What's new with the latest Bluetooth mesh specification? Explore mesh 1.1 features that improve security and network efficiency, reduce power, and more....
Sep 20, 2023
Qualcomm FastConnect Software Suite for XR empowers OEMs with system-level optimizations for truly wireless XR....
Sep 20, 2023
The newest version of Fine Marine offers critical enhancements that improve solver performances and sharpen the C-Wizard's capabilities even further. Check out the highlights: γ-ReθTransition Model and Extension for Crossflow Modeling We have boosted our modeling capabi...
Sep 20, 2023
ESD protection analysis is a critical step in the IC design process; see how our full-chip PrimeESD tool accelerates ESD simulation and violation reporting.The post New Unified Electrostatic Reliability Analysis Solution Has Your Chip Covered appeared first on Chip Design...
Sep 10, 2023
A young girl's autobiography describing growing up alongside the creation of the state of Israel...

featured video

TDK PowerHap Piezo Actuators for Ideal Haptic Feedback

Sponsored by TDK

The PowerHap product line features high acceleration and large forces in a very compact design, coupled with a short response time. TDK’s piezo actuators also offers good sensing functionality by using the inverse piezo effect. Typical applications for the include automotive displays, smartphones and tablet.

Click here for more information about PowerHap Piezo Actuators

featured paper

An Automated Method for Adding Resiliency to Mission-Critical SoC Designs

Sponsored by Synopsys

Adding safety measures to SoC designs in the form of radiation-hardened elements or redundancy is essential in making mission-critical applications in the A&D, cloud, automotive, robotics, medical, and IoT industries more resilient against random hardware failures that occur. This paper discusses the automated process of implementing the safety mechanisms/measures (SM) in the design to make them more resilient and analyze their effectiveness from design inception to the final product.

Click here to read more

featured chalk talk

Portable Medical Devices and Connected Health
Decentralized healthcare is moving from hospitals and doctors’ offices to the patients’ home and office and in the form of personal, wearable, and connected devices. In this episode of Chalk Talk, Amelia Dalton and Roger Bohannan from Littelfuse examine the components, functions and standards for a variety of portable connected medical devices. They investigate how Littelfuse can help you navigate the development of your next portable connected medical design.
Jun 26, 2023
10,878 views