Curiously, I would almost have believed Microsoft to have been the first to make a move like this. They have already been preparing their developer ecosystem for an architecture independent target for years with .NET and CLR/MSIL. As more software is developed in C#, switching CPU architecture is just a matter of supplying a new .NET VM bundled with the OS, and all your legacy software should continue to run - at full speed, even. (Incredibly, they decided that their ARM version of Windows 8 should be called "Windows RT" and be rather limited! What a missed opportunity!)
Meanwhile, Apple's developer tools are still churning out x86, x86_64, and/or arm assembly from Objective-C, so all existing software would at the very least need a recompile (hope your vendor is still around and has written portable code!) Or they could do another Rosetta, translating x86_64 to ARM. Doesn't sound like an efficient solution, though. And after a few years they'd drop the emulator from the OS anyways :P
> Incredibly, they decided that their ARM version of Windows 8 should be called "Windows RT" and be rather limited! What a missed opportunity!
The whole "Windows RT" thing has been horrifically mis-managed. If they're not going to let third-party desktop apps run, they should've used it as an opportunity to ditch the desktop altogether. And talk about bad branding... As if any normal consumer is going to have a clue what that's about.
I might be running more .NET software than I realize, but it seems to me that .NET isn't anywhere close to becoming the majority "instruction set" of software shipped on Windows.
Agreed. Although Office staying Win32 sure doesn't send the signal to others that its worth the effort to move software like that to .NET. Anyway, I'm always surprised how few things seem to be .NET, here nearly 11 years after it was introduced.
That's an easy problem to solve, as Microsoft would be around and able to supply that. As long as 3rd party software is delivered as .NET .exe files they should easily run, probably even when p/invoking, as long as the OS comes with the necessary standard .dlls. Actually I'm quite certain Windows RT already has all this solved under the hood.
I'm pretty sure binaries are still compiled down to machine code, so that would require your vendors to stick around and recompile and redistribute updated .app files for your old software.
It seems risky to invest so much in your own chip design without owning a fab too. If they really want to go down this route, I'd expect a purchase of TSMC or similar. And you're not going to stay competitive for long unless you invest heavily, at least on the scale Intel is. Apple users have watched their computers slip behind before with PowerPC, I'm not sure if they'd have the patience to see that happen again.
A problem with that approach is that owning a top-of-the-line fab is expensive because you have to buy a new one every few years. Every next generation is more expensive than the one before it.
I would think owning a fab just for the production of chips used in Apple products would be too expensive to consider. Owning a fab and selling chips to others, to me, looks to go way too much against Apple's culture.
"Apple users have watched their computers slip behind before with PowerPC"
I think that is exactly why Apple has a backup plan to move to ARM. If Microsoft is successful at moving to ARM with Surface, they will have to follow.
Why would it be too expensive? How many fab's are there (so, which % of worldwide output does each do), and how much % of all intel chips is bought by Apple? If the numbers are somewhat equal, they buy the capacity of one fab anyway. Then they can just as well buy the fab itself.
I guess Apple buys less than 10% of Intel's x86/x64 chips. http://en.wikipedia.org/wiki/List_of_Intel_manufacturing_sit... shows Intel runs at most 6 or 7 plants that could do sub-40 nm chips. So, that would make Apple's part at most half a plant or so.
Finally, I guess that buying a plant is not sufficient. They also would have to license tons of patents. Without relevant patents to exchange, that would IMO be prohibitively expensive.
Putting aside the fact that the fab takes a healthy chunk of profit, the question is one of capacity. A fab is under no obligation to provide Apple with chips, and given a choice between one big contract with Apple or diversifying and having a dozen smaller contracts with other manufacturers and I know what I'd pick.
The problem then, for Apple, is that they can't just turn around and get their chips made somewhere else. There just aren't enough fabs in the world to produce them at the quantity Apple needs, especially using latest-generation processes.
Which one would you pick? The one with AAA rating that pays half up front that pays well for state of the art stuff, or the dozen smaller ones that seem more concerned about your pricing than about the quality of your products? Yes, I probably am exaggerating, but I do not think the choice is as clearcut as you indicate. There is risk in taking on a customer that is larger than you, but there also is a lot of potential profit there.
One of the reasons for the Mac's success, during the last 7 years, has been the x86 architecture. They better know what they're doing - I would hate for history to repeat itself.
x86 has been a follow-on benefit to the evolution of OSX, particularly after Panther (10.3). Since OSX is based on FreeBSD, it was a short hop to x86 once they got the OS kinks ironed out (and their PowerPC arrangements expired).
For Apple, leaking news like this makes sense for a few key reasons:
1) They obviously are eager to take another step towards complete vertical integration, giving them even greater profit margins
2) Apple made it known wanted to make their Macbook pros as thin as their Macbook airs earlier this year, but the (relatively) high TDP of intel's mobile chips would've scorched users laps.
3) It's an obvious message(and challenge) to intel that they have to do even better. Apple will likely continue their growth to the largest PC maker (if they aren't already) and Intel needs their business. They're giving Intel 5 years to show them something special.
There is no question in my mind that Apple will gradually switch from Intel to ARM. I don't think it will happen until 2014, when the first 64-bit ARM designs come out. At the current rate of improvement, ARM processors in two years will offer roughly 4X what today's chips offer (with a better power consumption profile than current low-end Intel designs). By that point, ARM performance will probably be "good enough" for lower-end machines (such as the MBA) to use ARM rather than Intel.
I also think it's possible that iOS will eventually become the successor to Mac OSX.
One thing in favor of the move is customization. Intel has done an amazing job of removing the customization options from the x86 eco-system. No NVIDIA chipsets and no hooking into the faster bus on Intel motherboards. This has to be a problem for a company like Apple trying to build something non-stock.
Also, I cannot imagine the whole "Intel paying people to clone the MacBook Air" was well received in Cupertino.
I find it incredibly hard to believe that iOS will replace OSX.
An iOS that would be capable of developing iOS apps as efficiently as Xcode on OSX would be a very different iOS from anything like the versions we have seen to date.
Betting against Intel in the long term doesn't seem to be a good idea. That said, I'm sure Apple's got their eye on the world's first 24-hour laptop, and I'm sure ARM could help them get there.
Money quote: "Both have strong battery life compared to many Android devices, but from our tests and experience, it’s clear that Intel’s chip is far more frugal with power than the dual-core Snapdragon S4."
No, because Intel isn't shipping in the high-volume mobile platforms currently in major use [1]. Because as of October 2012, publications are talking about Intel's "first real smartphone".
I'm not talking about engineering capability, but rather shipped units.
[1] Yes, I know you use one of the few Intel mobile phones in use. But your phone's model doesn't rank on Google Analytics for any major site. That's what I mean by "in major use".
Intel hasn't been doing to hot lately; wall street is definitely betting against them now, and I think they are taking a long term outlook because Intel still has good profits.
What makes you think Intel will eventually stop the slide and get its mojo back?
Just sheer force of will. Intel has the engineering talent, the experience, the motivation and the capital. If they can't do it, who can? Apple has a lot to prove here, and so far all they've achieved is purchasing a few smaller chip design firms and managing to adapt existing ARM cores for their own SoCs. They have a long way to go to be able to be competitive in this area. The one thing going for them is that they have the capital to burn, and I can't think of a better way to use it.
Intel was washed up when the Athlon came out and was faster. Intel was washed up when the pentium 4 was too hot. Point being, intel has done pretty well for a company rendered obsolete a decade and a half ago.
Agreed. They've also got a big process-node lead on everyone else in the market; I find it hard to believe they can't leverage that to optimize whatever processor design parameters they need to.
The process node lead won't last forever though. We're going to reach the end of silicon soon, by the mid-2020s at least. Whatever replaces it isn't necessarily going to be from Intel, because they don't have expertise in much besides silicon. I wouldn't be surprised if it's another player, like IBM, that finally cracks it.
A laptop that doesn't need charging throughout the day, sure, but I don't think charging a laptop overnight is a significant inconvenience for most people?
There's no need to assume that a switch for some Macs will be a switch for all Macs. Multi-architecture binaries were standard for several years during the x86 transition. As they move to an App-Store model, it will be relatively simple to download the right binary based on architecture. Signed binaries could be required to be multiplatform. The minority of users who want to install software that's not Apple-approved will have to deal with potentially higher amounts of complexity.
It's seen a big spike up and is ~ 30% more than Intel's $2.6 billion/quarter. And it spent three times in Q3 than Google, 4.8x Microsoft and 3.8x Amazon.
Speculation in the comments are that Apple is paying an as yet unnamed firm, probably TSMC, to build/tool/operate one or several ARM SoC fabs.
I know things have changed a lot since the PPC days, but it seems like this might not be the best idea, and that Apple's history might point this out.
I can see it for iOS devices, but for a legacy computer part of what's attractive to me about Macs is the base compatibility with commodity PC hardware. Of course, I also am not the hugest fan of the move toward merging iOS features into the desktop OS, so maybe I'm just being old fashioned about this.
My speculation (completely not based on any knowledge - just what I would have done had I been in Apple's place)
1. Buy AMD (or Cyrix or one of the other companies that has a working AMD64/x86 chip)
2. Build a laptop that has both an acceptably strong AMD64 for the time, and a ridiculously strong (but scalable) ARM - say, a 16-core or 64-core 64-bit ARM core, which can scale its power.
3. Politely ask app developers to ship 3-arch fat binaries: AMD64+ARM64+LLVMIR (politely ask might mean refuse in the Mac app store otherwise). Well, the first two are actually optional, but recommended. Or the last one is optional but recommended.
4. Introduce a laptop with an OLED/color eInk (or other very low power) display, which can run either ARM64 or AMD64 or both, and can scale the number of cores. And an API that would let an app switch seamlessly between those modes.
5. Tell people "your laptop can do 24 arm-core-hours (so, 2 hours using 12 cores, or 24 hours using one core), or 6 amd-core-hours. You pick the software, you choose.
6. Watch as people (hopefully) prefer the amd64 mode thanks to its long life.
No company except Apple is in a position to pull such a thing. Maybe Apple can't either - but if anyone can, it is Apple.
I could definitely see them going ARM in the MacBook Air line, but I think they'll keep Intel for a while for their desktops (power usage isn't a concern) and the MacBook Pro ("pro" users will need the extra power and compatibility of the Intel chips, at least in the near term).
I'd be surprised if Apple hasn't been investigating alternatives to Intel chips since the day they switched. Not necessarily out of any dislike for Intel, (I think the switch has worked out quite well for Apple), but rather to remain nimble and be able to jump ships if Intel ever ran aground like the PowerPC consortium did.
realistically ARM currently lacks the raw power intel chips provide. you can argue about battery life but most work is still done in offices where power sockets are not an issue.
it might change in the future but.. i don't think arm will catch up with x86 for at least a couple of years - in the meantime intel won't sit around doing nothing.
it was in the past appealing to creatives, designers, video producers, the publishing industry etc I believe those are processor-intensive applications that don't fall in the enterprise sector.
I understand even though apple tried to move out of the server market, every creative company offices i have visited they mostly work with apple products.
I also would not be surprised if Apple builds a fab, possibly operated by Samsung or GloFo. Apparently a lot of the tooling in Foxconn's factories is actually on Apple's books, so it wouldn't be a huge stretch to apply a similar approach to making chips.
ultimately apple doesn't want to be dependent on suppliers. I guess CPUs and displays are the next obvious things. not necessarily a good thing - this will lead to de-standardization of components, more undocumented hardware and drivers.
Apple should migrate from x86 to LLVM IR. Then JIT down to native code upon program installation. That way they can switch the underlying architecture as much as they like.
I'm surprised they haven't adopted this scheme with iOS already when they deprecated GCC.
I'd be surprised if they weren't exploring it. But that doesn't mean they're going to make the switch; it only means that they're keeping their options open.
Compiling for Apple's custom chip would require using a proprietary version of LLVM/Clang, and resulting binaries could only be distributed via the Mac App Store.
It doesn't matter because they've already locked it down on the demand side. You can distribute iOS apps anyway you want, but people won't be able to install them.
