9 ms·
Apple almost certainly have a MacBook Air based on one of these chips at prototype stage. There are many reasons in favour, including keeping negotiations with
by fidotron 13y ago
Apple almost certainly have a MacBook Air based on one of these chips at prototype stage.
There are many reasons in favour, including keeping negotiations with Intel over price interesting, but probably the main thing preventing them running with it would be an inability to manufacture the chips fast enough, which is a major concern in mobile land. This is why lots of Android devices exist in variations based on different chips as hedges by the device manufacturer on long term availability.
- BugBrother 13y agoThe volumes for desktop/laptop are almost trivial compared to the volumes for handheld. (At least for Apple.) So making the processors in volume for a Macbook Air would probably not be a problem. Also, Apple probably have little problem getting preferential treatment from manufacturers.
- masklinn 13y ago> The volumes for desktop/laptop are almost trivial compared to the volumes for handheld. (At least for Apple.) Yep. IIRC Apple ships something like 10 million laptops/year. They ship 3 times that in phones… every quarter
- sliverstorm 13y agoI would think porting OSX to ARM would be the real hurdle? Not undoable by any means, but the lion's share of the challenge.
- wiml 13y agoThe machine-specific parts of OSX already run on ARM in the form of iOS. Also remember Apple has already successfully made two or three architecture transitions already: m68k to PPC to i386 to x86_64.
- justincormack 13y agoAnd the (brief) PPC64 transition.
- mcculley 13y agoI wouldn't imagine porting OS X to ARM would be the hurdle as most of it is already done in that iOS is most of OS X. Apple has full control of that source code base and probably already has done this, like they did during the transition to IA-32. It would be the third party applications that would be a hurdle. Without a transparent layer like the deprecated Rosetta, they would not be able to run existing applications and would have to explain that a new MacBook Air can't run all of the old MacBook Air applications. Maybe if they come out with an ARM powered laptop, they will call it something other than MacBook Air to avoid that confusion.
- gonzo 13y agoJust the Apple Air, I'd bet. Don't forget that Apple has spent years getting everyone on Xcode, and disciplining them to avoid the parts that would make a recompile & test straight-forward. They also have a "good enough" office suite (for many people), as well as the iWork apps. Such a device could potentially also run iPad apps without much change.
- mikeash 13y agoThe real challenge will be figuring out the compatibility question for third-party software. Do you make everybody recompile before their stuff works on the new hardware? Do you ship an emulator for x86-64 for a while, like they did when they went PPC->Intel? OS X and its predecessors have already been ported to run on a bunch of architectures: x86-64, i386, PPC64, PPC32, PA-RISC, SPARC, and Motorola 68k. All, or nearly all, of the CPU-dependent parts of the OS are the parts that are shared between OS X and iOS. Making OS X run on ARM would be trivial for Apple, and I'd be shocked if they didn't have it up and running already as a hedge.
- endianswap 13y agoThat was my thought, too. It seems like if they do this then they'll be going down the same path as Microsoft did with the Surface RT and Surface Pro, right?
- twoodfin 13y agoNot exactly. Remember that the Surface RT deliberately restricted the applications that could be run via Win32 on the familiar desktop. Just about every third party application needed to adopt the new RT APIs and run "Metro"-style. If they go down this road, Apple will not put constraints like that on their Mac developers: I'd expect that all the most commonly used frameworks would continue to be available, and porting most applications would amount to a recompile against a new Xcode.
- rmrfrmrf 13y agoI never once gave much thought to the idea that Apple would somehow shut out unsigned apps from its desktop computers, for the main reason that there would be too many existing apps that would suddenly lose functionality and cause a backlash. With a port to ARM, though, Apple can simply say that the developers haven't ported their app to the new architecture yet, and that more apps will become available as developers catch up. Meanwhile, all those apps that currently require some kind of lower-level access could be banned. On the other hand, I think that would be a huge boon for non-power users; it would be nearly impossible for malware to get onto the computer, and even annoyances like Adobe's and Microsoft's auto-updaters would finally get funneled though the App Store, which would prevent programs like that from constantly occupying memory/CPU/network. For this to work, though, I think Apple would be wise to include some kind of developer mode feature (perhaps even forking over the $99/year fee) that would allow unsigned or potentially dangerous apps to run. All of this (admittedly wild; sorry, coffee is kicking in) speculation definitely has me excited for the future of Apple, though! I haven't felt like that since Steve was around.
- rsynnott 13y agoGiven Apple's history with this stuff, there's a very good chance that that's already done. Intel was supported internally for years before the PPC -> Intel change.
- cpeterso 13y agoJobs claimed that Apple maintained a secret x86 port of OS X for five years before the public release. A small cost.
- leoc 13y agoApparently this is true enough, with the added qualification that for the first year or so it was largely secret from Apple too. :) http://www.theregister.co.uk/2012/06/11/apple_project_marklar_secrets/ http://www.theregister.co.uk/2012/06/11/apple_project_markla... http://www.quora.com/Apple-company/How-does-Apple-keep-secrets-so-well/answer/Kim-Scheinberg http://www.quora.com/Apple-company/How-does-Apple-keep-secre... (Though of course the fact that the OS X codebase had been kept cleanly portable was neither one person's secret project nor a matter of chance.)
- rsynnott 13y agoMakes perfect sense, really; not only would it be a hedge against having to adopt Intel, but just the value of having it around to show IBM people when negotiating over the PPC would probably have been worth the cost.
- gozzoo 13y agoI don't think they will go that path. It would make much more sense to introduce a desktop version of iOS itself. iOS has already everything that's needed for a light desktop OS. It would provide much better experience than ChromeOS, there are already thousands of applications doing about anything and it would require very little effort to adapt iOS to run as a desktop OS and to adapt the existing applications. I think that a hint for that is the recent port of Microsoft Office. If users want more sophisticated OS they can just use 13" MacBook Pro. It's quite easy to guess that the next version will be thinner and lighter and probably cheaper - very similar to the current MacBook Air.
- coldtea 13y agoThey've already ported it. iOS is OSX for ARM plus different UI stuff -- all the kernel, basic userland etc are there. So, it's mainly a matter of porting the higher level stuff -- mainly the Cocoa libs, which are slightly different on iOS vs desktop OS X.
- sliverstorm 13y agoI guess I'm not familiar with just how much iOS and OSX shares.
- userbinator 13y ago> but the lion's share of the challenge. This would've been the perfect phrase last year.
- mx12 13y agoI don't think that Apple will completely get away from x86 for a long time. Attempting to emulate the x86 on an Arm would be terribly slow. I do however, think that they will eventually include both arm and x86 processors in the Macbook Air. That way, backwards compatibility is preserved and low power apps can run on the arm. In the current Macbook Pros they have dynamic switching of GPUs, there's no reason they couldn't use the arm as a coprocessor or even run the full OS. Here a few technical points: * LLVM - You can compile once for both both architecture and then the JIT will take over compiling for the specific architecture (Take a look at llvm for the OpenGL pipe line in OSX) Full screen app- When an app is full screen (if it's a low power app) then the x86 could sleep and the arm could switch to running the app. App nap - If all x86 apps are a sleep, switch over the running the arm processor exclusively *Saving State - It's possible to save the state of apps in OSX, a similar mechanism could be used to seamlessly migrated between processors. This is pure speculation, but it is feasible. There would be many technical challenges that Apple would have to solve but the a capable. The advantage Apple has is that they have absolute control over both platforms.
- fidotron 13y agoThat is an interesting idea. At one point I had a machine which allowed movement of data between apps running in Windows 3.1 on a DX4 and Risc OS on a StrongARM. I'm wondering how hard it would be with OSX (a far stricter OS than Win3.1 or Risc OS) to allow a sort of process level separation, where the OS and any ARM compatible processes are running on an ARM, but you keep an x86 around and spin it up for certain processes.
- metrix 13y agoThis sounds like it is ripe for a Semi-custom chip from AMD, where they sell an ARM/X86 SOC
- legulere 13y agoNah, LLVM is to slow for JIT. However the final compilation step still could be done at install-time or link-time.
- lallysingh 13y agoIf they wanted to, sure. They have all the infrastructure ("fat binaries") from the ppc switch.