Intel outside: Apple 'prepping' non-Chipzilla Macs by 2020 (stop us if you're having deja vu) Apple is once again reportedly working on switching out Intel processors for its own homegrown, presumably 64-bit Arm-compatible, CPUs in Macs. The changeover could happen as early as 2020, according to Bloomberg today. iPhones, iPads and other iThings use Arm and Apple-designed chipsets to run software, while the desktop kit …
Xeons are nothing more than a v big. Cache and tiny cores.
Given good compilers and strict coding practices - and stricter test harnesses, producing complex, cpu portable code is a piece of piss.
Just be careful on unintended word alignment and threading issues.
Intels not having a good 2018, are they.
Apple doesn’t like announcing things which aren’t ready or close to ready. Having things leaking 2 years early is either an attempt to manipulate the stock price and there is no substance behind the rumour or an unfortunate incident which could have serious financial consequences?
I'd think that Xeons are a tiny fraction of the Intel CPUs Apple ships as they are probably only in the Mac Pro.
And you say by simply making everything a lot more complicated producing cross platform code is really easy. In the world of less complex tools in linux I have noticed over the years how many issues there have been making/maintaining portable code across CPUs even on the same OS.
Certainly helps to have a transition layer like Android did with java-like experience, and Apple did when they moved to x86 from PPC.
Will be interesting to see if at some point they start shipping their ARM chips in their laptops(I think they already do for the touch bar stuff), and be able to run ARM and x86 stuff side by side at native hardware speeds in some way.
This could be anything from an attempt to create a lower end laptop a la Chromebook with better performance/energy characteristics than they could achieve using Intel chips to a way of end-to-end controlling the entire ecosystem with a handy side effect of removing Hackintosh boxes from it (although I believe they tolerate and don't care about that side ecosystem due to the potential for up-sell).
>They care enough to make sure it's near impossible to run iMessages on one.
That'll be to protect the integrity of the service from the kind of system built by the kind of person likely to know enough to get into it via some nefarious exploit or, conversely, ignorant and foolish enough to have followed a guide and got themselves infected along the way. The service and brand are far more significant/profitable than the Mac hardware - they make their money from the iPhone and really I'm almost (but not quite) surprised they're still even in the 'computer' business any more.
Not while they've still got their BFF in Redmond to ensure their OS will slow down their next generation of hardware.
Until that little co-dependent facilitating partnership is broken up they will be BAU until the chips get down to 1 atom thick insulators on the gates.
The Mac was 68000-based for a decade from 1984 until 1994, then PowerPC-powered for the 12 years from 1994 until 2006, so by 2020 will have had Intel inside for 14 years.
Now that we all sit atop compilers and execution units are so far divorced from instruction sets, it feels difficult to get very emotional about it. If it were to happen, it'd be more interesting to find out what Apple would use the opportunity to eject from the legacy software stack. I think there's too much of the Objective-C runtime underlying Swift's optional dynamic dispatch, and it still has a substantial role in bridging to C++ but I'm sure other candidates would present themselves.
OSX had always had a secret shadowy x86 build - NextStep based OSX prototype Rhapsody could run on x86, they kept this going until 2005.
This obviously helped with the transition.
So, it would be interesting to know if they already have OSX compiled for ARM - given the IOS branch it wouldn't be a huge surprise.
Quite. I had a PC (x86) running NextStep for a few yeasr (the sponsors would not fund a machine - although they were happy to pay for a verty decent Intel based machine with additional software. I have a suspicion, it was a long time ago, that I didn't list the software. Ran perfectlly well.
The end game, perhaps another 5 or 10 years from now, is to move the entire computer into virtualization. Then Apple could build the Mac using any old hardware; wouldn't really matter. Just port the legacy hardware emulator and load the Mac.
>Just port the legacy hardware emulator and load the Mac.
Why would anyone bother?
Machine with kernel+container of binaries = cloud service.
No-one's gonna have apps in future - you'll have a link to service hosted somewhere 'convenient' that isn't on your machine so you can be charged per use.
Look at Android with its 'instant' apps - that's the future, not VMs or emulators.
I'm sure some young Apple Exec thought this would be a bold new idea- make our own CPUs! Then in 20 years time some other Exec will suggest they outsource to Intel- the circle of life continues and compiler compiles more buggy code.
Microsoft's approach has every chance of success.
The main difference will be in the driving forces.
With Apple, the transition to Intel was complete because they forced it to be. And that's OK, because you are going from a rare desktop class chip to a common desktop class chip, which as well as being capable to run native software, gave you extra capabilities in running dual boot, etc.
The question with ARM chips is how many consumers want it. If enough users flock to Windows ARM, it will thrive. But then they will also keep the Intel side going as long as there is demand too.
Will Apple try to force everyone over to ARM? It's possible, and they'll certainly take some of their users with them. But they might just lose some.
I am a consumer. I do not write assembler code any more. I think it is extremely likely that only OS implementers do that, and then only for certain critical pieces of code where detailed profiling has shown it will significantly benefit performance. Please tell me why I should care whether my C or other compiler level language is executed by an ARM, Intel, Motorola, MIPS, IBM, or other processor.
Please tell me why I should care whether my C or other compiler level language is executed by an ARM, Intel, Motorola, MIPS, IBM, or other processor.
The endless merry-go-round of version upgrade fees on all your major applications, sometimes because a lot of work was involved and other times just because they can?
In many ways, it was simpler when CPU instruction sets were far smaller. Today you have a lot of extensions for multimedia, encryption, etc - and they may be less compatible than simple move or jump instructions. Low level details like CPU-specific optimizations, threading, cache access coherency, etc. are also not irrelevant for high-performance and heavy-load applications. Some of these can be shielded by good libraries and frameworks, but not always.
For example, Adobe had to work with Intel to speed up Lightroom performance (not everything runs on a GPU, even today). As long as both Apple and Windows run on Intel, the work is useful on both versions of the product. If they had to optimize the code for very different architectures, it becomes pretty more difficult.
Of course, it depends on what applications you write. Simple, single threaded, CRUD applications will no issues.
@ tom dial
A few things matter for your C code.
e.g. size of common objects such as an int
e.g. endianness - if you have some bitshift operations (quite common in C) then unexpected results on opposite endian architecture
.. there are plenty more
caveat - depends how clever your compiler / build routines are when you specify the target OS, such things as mentioned above may be handled OK ... or they may not
Bit shift is endian-independent as its defined on the full logical word, not its in-memory representation; mistakes tend to manifest when talking about serialisation or any attempt at sub-word access. Also sometimes in latent misuses of or deliberate endian-assumptions within a union.
"Please tell me why I should care whether my C or other compiler level language is executed by an ARM, Intel, Motorola, MIPS, IBM, or other processor."
Well, for one thing, I believe the A-53 architecture doesn't have speculative execution and is Spectre and Meltdown immune. In future as other vulnerabilities are discovered, choice of processor may have quite a big impact on security.
I think the issue is really about such things as memory management, security levels and context switching in the Deep States of the OS.
CPUS are not just fast z80s with lots of RAM.
A LOT of code under the hood goes into making them LOOK like that. But they are multi cored cached to the hilt security level conscious fickle brutes.
I know enough to know that I dont know nearly enough to say more than that.
" ... Microsoft's approach has every chance of success. ... "
Um ......
Can you say Microsoft Surface RT?
That went over well didn't it.
It means porting EVERY software app over to run on ARM. Not that it can't be done. It can be. But just how happy will a software company like Adobe (just to name one ) be with doing it?
@Lost all faith
Thing is, they claim their emulation layer performs well ... I doubt it, seriously, and given the hardware you need on Intel/AMD kit to get a somewhat well performing OS, well, I doubt the emulation layer will cut it ... and op explicitly mentioned Adobe, like, Photoshop emulated on Arm ? Are you nuts ?
Full blown Windows is a resource hog on Intel, who in their right mind thinks one can squeeze that on ARM ? And I'm not even talking EMULATION, here, yet ...
So, we have read the articles, we all think it is just hot air, not gonna perform anywhere near what they claim, success will not happen ... just like RT.
Ohhh, and, the emulation emulates a 32-Bit CPU, which means 3Gb* RAM max per app, if they get it right.
How many more times will I have to write this out ?
* 3Gb max means 1.5Gb max for the unlucky windows luser.
"Photoshop emulated on Arm ? Are you nuts ?"
Well, that just opens the door wider for Serif Software's Affinity Photo program, which has Photoshop-level capabilities and currently runs on iOS, MacOS, and Windows. (...and SELLS for $50 -- no subscription needed!) (Serif ALSO makes an Illustrator competitor -- Affinity Designer -- and is working on a page layout program to compete with InDesign. I'm hoping to get my employer off the Adobe Cloud crazy train as soon as I possibly can!)
Trust me: If it means losing their market, Adobe will adapt.
"I’ll put money on Apple making this a success before Microsoft (who are supporting the launch of ARM based Windows 10 laptops, this year) and friends."
Probably, because apple tend to go for an all or nothing approach. In 2007 if you wanted a mac you were buying an intel mac. When MS release Windows for ARM you will still be able to go out an buy an x86/64 machine and run windows on it..
We seem to forget that Apple are at their core (no pun intended) a hardware company which writes software and MS are at their core a software company who make some hardware.
We cant really compare Microsoft and Apples efforts in this area Apple have an opportunity to force new sales down a specific route, with MS (or indeed linux) you will have the choice to run it on whatever hardware you like - I really dont think that the demand is there for ARM Windows (Not without some decent emulation to keep x86 apps running)
Maybe if MS decided to stop selling windows to third parties so that if you wanted a windows machine you would have to buy one of their surface range then we could start comparing. Until then comparisons between MS developing windows for ARM and Apple building new ARM based machines are almost literally comparing apples to oranges.
I get emotional, because the ordinary Mac user is likely to have to buy new copies of some software at great expense.
More importantly, though, since you can't buy the Apple processors used in iPhones and iPads to put in your own products, these new processors, if Apple can have them made, won't further the ARM ecosystem that much.
And since their volumes are limited by the Mac market, it will be hard to justify development costs.
If they thought it was hard getting a choice of PowerPC chips to work well in laptops... this could be the prelude to the demise of Apple. Or at least of the Macintosh.
Existing machines won't stop working, nor will their CPUs change the instruction sets they use.
It would be interesting to see them try though.
How awesome would a CPU with multiple instruction set capabilities be? A toggle feature between x86, ARM and PPC would be interesting. Monday, you have PPC, Tuesday you've got ARM then by Wednesday you're running x86 :-D.
Granted this is almost impossible, but interesting non-the-less and would be amusing if OS's could switch it. It would make patch Tuesdays interesting.
A laptop with multiple architectures is fairly trivial - Apple already make one. Their chip that runs the touchbar is ARM.
No reason the primary CPU can't be ARM, and have an application that requires x86 or 64 run on a discrete x86 chip. To do it crudely would just require treating the x86 as a separate machine and using MacOS's equivilent of XWindows.
The idea of silicon sitting doing nothing is common - its central to the Big.Little design of many ARM-based chips
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
