Apple A processors in Macbooks

[brdeveloper]

The whole reason for the original ARM-based Mac rumors was because of the rapid increase in performance of the A Series chips and the fact it was believed that you would need the low-power efficiency of ARM in order to make a super thin, fanless Macbook Air.

Apple was able to do this with the new Macbook with core M. Core M pretty much kills any need for ARM. Intel pulled through.'

Considering the huge mess and the amount of compromises that would have to be made(such as losing bootcamp, creating fragmentation, etc) Apple isn't going to switch to ARM just for the sake of switching to ARM. Also, unlike the switch from PowerPC to Intel, there no ARM chips powerful enough to replace the whole line up of Macs, especially Macs like the Mac Pro. Fragmentation would be for years, make it hard for Mac developers(Now they would have to make sure their Mac apps run on ARM if they want to be in the Mac App Store), and would probably cause more harm than good.

Fragmentation already exists in a broad sense if you remind that iOS devices run on ARM processors. I think that there is a market for devices which would support both iOS and a few modern OSX apps. It would be a crossover device which would give all iPad features and also a few other OSX features. For a more uniform UI, it could only allow OSX apps running in fullscreen.

 

[dmccloud]

It would, if they were recompiled to the ARMv8 instruction set. Apple already has the necessary technology (cross compilers + fat binaries) as well as the experience (PPC/Intel and Intel32/Intel64 transitions) and could pull this off easily. I am sure they have full OS X versions running on ARM machines in their test labs...

IA64 (Intel's implementation of 64-bit processing) was scrapped in favor of the AMD64 implementation, because the latter maintained x86 compatibility whereas IA64 was built for the Itanium processor, which went nowhere in the face of AMDs dominance at the time. There's still a lot of work involved in converting x86 to ARM that goes beyond just fat binaries and cross compilation. How would Apple handle system level calls from the x86 side that have no ARM equivalents? It's crazy to see people attempt to negate the complexities on all sides of the equation when porting platforms.

 

[0007776]

I think the bootcamp issue would be one of the smaller problems in such a move.
You'd need to get a new OSX that supports the ARMv8 and then get developers to recompile all their apps and just recompiling them will only be enough for some apps. Big important programs like the creative ones would need to be rewritten. The ARM chip lack a lot of the Mediaextensions so it will even be slower than one would expect in media producing film/music/picture applications.

The big problem would be with getting developers to port their apps over and having enough power to have something like Rosetta for the ones that aren't ported yet. I'm sure apple has a version of OS X that runs on ARM somewhere in a back room of their headquarters just like they had an intel version in secret for years before they announced the switch.

 

[brdeveloper]

IA64 (Intel's implementation of 64-bit processing) was scrapped in favor of the AMD64 implementation, because the latter maintained x86 compatibility whereas IA64 was built for the Itanium processor, which went nowhere in the face of AMDs dominance at the time. There's still a lot of work involved in converting x86 to ARM that goes beyond just fat binaries and cross compilation. How would Apple handle system level calls from the x86 side that have no ARM equivalents? It's crazy to see people attempt to negate the complexities on all sides of the equation when porting platforms.

There are tons of solutions to this problem. Some of them are in execution time, like a driver. GPU drivers do this every time. Compiler-time solutions are solved by the compiler. Even in the x86 world you can compile a program to enable support for newer instructions sets. Fat binaries can do the trick as you basically need compiling your project for various architectures. What was the last time you needed coding assembly directly into your .c or .cpp file?

I already did this just for fun and learning purposes around the early 2000s, when we could easily mess with the operating system memory (at least on Win9x). Since Windows 2000, viruses started requiring some kind of user interaction to take over the operating system - or explore a security hole to get administrator access. Unless you're coding a device driver, you don't need dealing with interruptions or machine-level instructions.

In short, if you do a for, a printf or instantiates a class in X Code, it doesn't matter if the target architecture is x86 or ARM. The compiler will apply the proper mapping to low level instructions.

 

[brdeveloper]

The big problem would be with getting developers to port their apps over and having enough power to have something like Rosetta for the ones that aren't ported yet. I'm sure apple has a version of OS X that runs on ARM somewhere in a back room of their headquarters just like they had an intel version in secret for years before they announced the switch.

You'll only need a Rosetta-like solution if you need running a legacy, discontinued apps or complex software which is bundled with some kind of proprietary driver/plugin... I can't imagine why Pixelmator or Google Chrome couldn't be offered in the launch date. Of course, some kind of build customization should be made in Chrome's case (like building it without Silverlight, at least until Microsoft provided an ARM build).

I imagine such device in the form of a tablet which could initially run "selected" OSX apps. With time, the app list would increase as developers produced new builds.

 

[leman]

IA64 (Intel's implementation of 64-bit processing) was scrapped in favor of the AMD64 implementation, because the latter maintained x86 compatibility whereas IA64 was built for the Itanium processor, which went nowhere in the face of AMDs dominance at the time. There's still a lot of work involved in converting x86 to ARM that goes beyond just fat binaries and cross compilation. How would Apple handle system level calls from the x86 side that have no ARM equivalents? It's crazy to see people attempt to negate the complexities on all sides of the equation when porting platforms.

What does instruction set has to do with system level calls? The current ARM (as used in iOS) and x64 have the same base type sizes, alignment and endianness. So if your code (no matter whether its system-level code or user land code) is written in C/C++/Obj-C, you can compile it to ARM and just be done with it. The only real problem would be programs and libraries that explicitly rely on x86 (assembler/Intel CPU idiosyncrasies). Which nowadays is almost nobody.

Not to mention that iOS and OS X share most of their source code anyway, as its the same OS just with different user-facing GUI frameworks. So OS X system libraries are already compatible with ARM (either way, its not really developer's concern, as its Apple's job). Besides, developers who offer apps for OS X and iOS already have tons of shared code that compiles seamlessly between x64 and ARM.

 

[dusk007]

The big real difference would be a lot of money savings on Apple's side. Intel charges more than 10 times of what SoCs like the A8/9 usually cost. Though Core M will probably get cheaper after it looses its novelty.
I doubt Apple would pass them on to the user, they would just pocket a bigger profit margin closer to how it looks on phones. Ergo nothing to look forward too.

Regardless much trouble an ISA change would actually cause, I doubt they would only do it for half the Mac lineup. If they do it they'd switch all of it.