Jean-Louis Gassée, Monday Note:
In 2008, for $278M, Apple acquires Palo Alto Semiconductor, a semiconductor design company. Less than a year after the iPhone starts shipping, the intent is clear: instead of buying off-the-shelf ARM chips, Apple wants to design its own processors for future iPhones.
And:
Compared to modest first-year iPhone sales, spending $278M to acquire Palo Alto Semiconductor looks out of proportion. And, of course, let’s not forget a context where Intel reigns supreme having just “captured” the Mac. As always, references to Apple’s “well-known” arrogance are at the ready: Who do these guys think they are, what do they know about microprocessor design and manufacturing?
This is a great read. There’s insight into Apple’s path from 68K to PowerPC, the PowerPC to Intel, with lots of links and backup detail. And then Jean-Louis moves on to the possibility of iOS running on an ARM-based Mac, with both the good and the bad implications.
UPDATE: I originally wrote about the possibility for a speed increase for the Xcode iOS simulator. I started a Twitter thread asking about this and the response was pretty much no, that the code will be native either way (currently x86 code, if ported, it’ll be native ARM code, only difference would be if the ARM processor was significantly faster than the original x86 processor.)
This article carries a lot of if misconceptions. The iOS Simulator is not and Hardware Emulator, it is a Software emulator. It run an x86 version of iOS on top of macOS (it even uses the same core libraries than macOS, like Foundation, CoreFoundation, …).
And it runs x86 version of the iOS software on top of that layer. There is no such thing as “ARM code running on x86 hardware inside a heavy development environment”
The other major error is thinking that what prevent Apple to merge iOS and macOS is the Hardware. Apple can compile iOS for x86 without difficulty. The architecture dependent code is already shared between the 2 platforms. What prevent them to do it is the software part. How to handle arbitrary sized screen that don’t support touch in iOS for instance ?
+1 Dave, please correct your assertion about the Simulator. It’s a Simulator, not an Emulator.
An ARM mac might be able to, in fact, run iOS/ARM and the ARM apps you may have on the store unmodified, which would be a nice improvement in terms of testing. But I don’t think there’s any data suggesting a huge performance increase over iOS/x86 currently running on the Simulator.
Why does an Apple-made desktop processor have to be ARM? There were once many x86 processors on the market, Apple could certainly roll their own.
Yes and no.
As far as I understand it, everything new since the Pentium Pro era, more or less, is still under patent.
Unless Intel’s going to offer Apple a license for the newer x86/x64 stuff, Apple can’t use it.
Intel, naturally, has no incentive to sell Apple a license for less than it’d make selling Apple chips.
(Apple could certainly roll its own Pentium or maybe Pentium Pro era x86 implementation.
But that’s not competitive, and frankly they’d be better off just either buying modern chips from Intel or going ARM than trying a competitive but incompatible modernization of IA32 – they wouldn’t even have access to a 64 bit Intel extension set they could use!)
Bracketing the concerns below, if Apple really had some reason to want ARM access to Macs for iOS development, that’s no great reason, in itself, to switch entirely to ARM.
It’s a great reason for coprocessors or ARM-in-a-box-on-Thunderbolt systems, though.
Remember the days of 486 boards for Macs to let them also Be A PC at full speed?
(Nobody but Apple knows how much an A11 Bionic costs, but people guesstimate about $65.
If there was a need for it, Apple could probably sell one in a box with appropriate glue hardware for around $250, profitably – less if they just wanted to break even and sell it to devs.
But there’s no need for it, per below)
I’ve pondered that too. But the Apple team has enormous skills in innovating on the ARM architecture which might not translate to x86. Sigivald’s comment is also something I hadn’t thought of.
That’s not entirely true. AMD owns most of the IP that pertains to x64. They originally extended the x86 ISA to support 64-bits, which became known as AMD64…
“The original specification, created by AMD and released in 2000, has been implemented by AMD, Intel and VIA.”
At the time Intel was pushing the Itanium (IA-64) as the future of 64-bit computing. However, even that ISA wasn’t all theirs, it originated at Hewlett Packard.
If Apple decided to go this route, they would ditch the x86/32-bit support in the ISA, as they’ve done with their own ARM cores.
Personally I think Apple is developing their own ISA that can scale along with the OS; run on anything from the Apple Watch to the next Mac Pro.
And the reason for the “delay” in the Mac Pro has a lot to do with the new CPU… I’d guess they were planning on releasing it this year, but due to the “out of order execution” issues that plague current ARM and x64 designs, they went back and fixed it in their own ISA.
“One possibility that springs to mind is a huge speed increase for developers building iOS apps on a Mac.”
What the hell? No, most iOS apps run faster on the Mac than they do on a real device.
With the Ax chips that are currently in phones, yes, intel based macs are faster.
However, if the rumours are true and Apple is going to begin to switch Macs over to ARM in just 2 years, you can bet on it that Apple has made and tested AC powered ARM chips that are far, far faster than the ones we have seen so far.
A couple of people have touched on this, but I think one of the big things that would help transition to a different processor architecture is Bitcode. If information is leaked about Bitcode support for the Mac, that would be the confirmation of a new, non-Intel architecture Mac.