Good to hear. When Apple drops Intel, I will most likely have to drop Macs. That would break compatibility with so many OS X apps (and developers would take a great amount of time to recode their apps, assuming they did at all) and it would break Windows compatibility. As much as I like OS X, I occasionally need to use Windows.
Yes and no. It would break compatibility with Windows, but if Windows moves to ARM as as been speculated, you're going to have to deal with that breakage anyway.
As for compatibility with OS X apps, for 99% of apps out there, it would be as simple as checking an additional CPU architecture and recompiling. Here are a few reasons why an Intel to ARM transition won't be like the PPC to Intel transition:
- Almost everybody builds with Xcode these days, so there's no risk of the nightmare scenario we had with the Intel transition, where Motorola bought CodeWarrior and sold off their x86 toolchain a few months before the transition, forcing most developers to change IDEs while porting their code.
- Apple uses a little-endian ARM architecture, so you don't have a difference in byte order.
- Fewer apps use Intel assembly language code directly, relying instead on Accelerate framework and other similar libraries that already work cross-platform. (Photoshop and audio plug-ins are the exceptions that prove the rule, of course.)
With that said, I'm pretty sure the pundits are still wrong. Although I like the ARM architecture in terms of power-per-watt, and there's a decent case to be made for using them in low-end laptops (e.g. the MacBook Air), in terms of absolute speed, they don't pass muster. They would need to make the A8X four times faster if they wanted it to compete with the speed of the Retina MacBook Pro, much less the Mac Pro.
And then, there's the evil voice in my head that says Apple needs to create a mechanism for transparently migrating application state between x86-64 and ARM64 versions of an application in real time, allowing for ultra-low-power operation, kicking in the real CPU when it is needed, then cycling back, much like the way they swap between the integrated and dedicated GPUs... but this would require a very different compiler design that builds binaries for both architectures at the same time, ensuring that all the executable code is at the same offsets, that all the data structures are the same size, etc. (Yes, this would be nuts.)
So if all these iOS apps are compiled for three different binarily-incompatible CPUs, how come there's only a single app download from the iTunes app store? How does the one compatible version (out of three) find its way to my iPad?
It doesn't. Apple uses multi-architecture binaries that contains code for all supported architectures in a single file, so your 64-bit iPad gets both the code that it runs and the code that older hardware runs. Your iPad then chooses which slice to run based on its capabilities.
The answer is the iOS CPUs are all binary compatible, and there is a single executable download. Saying iOS runs in three different types of CPUs is like saying OS X runs on different Intel CPUs. The microarchitectural features may differ, but they are share essentially the same compatible binary instruction set.
Not true. The first iOS devices used 32-bit CPUs. Current iOS devices use 64-bit CPUs. So most store apps have both a 32-bit ARM slice and a 64-bit ARM slice. And when you compile for the simulator, you're compiling i386 code. There are your three architectures. (And you can also add an armv6 slice for older iOS hardware, but I'd probably call that a microarchitecture difference.)
This actually illustrates why it would be difficult. The xcode iOS simulator runs iOS apps on OS X *far* slower than the native iOS CPU. This is despite the Mac CPU being much faster than any mobile device.
Yes and no. The simulator can be slower for graphics-heavy tasks involving OpenGL because of all the extra abstraction layers (you're essentially running a window server on top of another window server). However, for general computation, the simulator is much, much faster than any iOS device, because the CPU is so much faster.
that already runs iOS software on OS X for the programmers coding iOS apps.
