Since the T2 was a variant of the A10 its possible that the T3 will include more and more functions - and maybe even be able to run full iOS apps albeit at lower performance. This way Apple can support the transition to ARM while providing more complete compatibility. For example running an iOS app could invoke Marzipan, and if this is not available use the T3 chip. A10 or even A11 chips are probably only costing apple in the 10's of dollars nowadays so it would not be expensive to add.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
ARM based MacBook Pro discussion [merged]
- Thread starter Omega Mac
- Start date
-
- Tags
- arm intel macbook pro macos sierra
- Sort by reaction score
There seem to be some huge misunderstandings about this ARM vs Intel thing.
The majority of modern Mac/iOS applications are written in high-level languages and use processor-independent frameworks to drive hardware (like Metal for graphics, Core Audio for sound etc.). Especially stuff written to Apple's App Store rules - and if we're talking about the new games developed specifically for Apple Arcade then I think its safe to say that they will all be written this way.
For software like that, ARM vs. Intel should be just a case of ticking the right box in XCode and hitting 'Build'. Of course, life is never quite that simple, but the problems are likely to be with big MacOS applications with loads of legacy code, ported Windows code, third-party plugins etc. (Office, Adobe CS, Logic Pro...). For iOS Apps, let alone brand-new Apple Arcade games, ARM vs Intel should be a complete non-issue as long as the developer is around to create a new build (and, unlike MS, Apple has a recent history of ruthlessly killing abandonware).
The main difficulty in porting between iOS and MacOS is that iOS uses a different "application framework" to MacOS and the user interface works in different ways (plus iOS software has to go in the App Store and follow Apple's strict rules). That means a lot of re-writhing of the high-level source code and redesign that has nothing to do with the processor type.
"Marzipan" isn't some sort of iPad/ARM emulator for iOS - its a new set of libraries and frameworks that let developers write Apps that can be compiled for both iOS and MacOS from the same source code. At the moment, developers still have to build two versions for iOS/ARM and Mac/Intel but in future they'll probably move to some of virtual-machine based system. The T2 chip can't take its place, and Marzipan will still be needed on an ARM-based Mac.
I'm guessing that using Marzipan well will require a bit of effort by the developers to make sure that the user interface scales and makes sense on Mac, and that complex apps written specifically for Mac will always be better, but for smaller-ticket items it could make the difference between Mac version and no Mac version.
I'm not saying that ARM-based Macs are not on the horizon, but Apple Arcade just isn't a clue one way or the other.
ARM-based Macs will have to tackle the issue of big legacy software and some users' needs to run (Intel) Windows and Linux.
I think everybodys responses here are great. However, I stick to what I said, I believe we will see the next round of MACs sporting ARM processors in addition to Intel. For Apple Arcade to be a trulry cross platform service (IOS,TVOS,MACOS) that uses local hardware unlike Googles new gaming cloud service they are going to want/need consistancy. And they wont start off with games cross compiled. This will also be used as the “killer app” to get folks to start moving the newer ARM/Intel Macs. Again, I stick to what I said. MACs with ARM chips in addition to Intel on board are coming for Apple Arcade.
Technically, this is exceedingly difficult to pull off and the resulting hardware will be expensive and also probably unreliable. At the same time, Apple has been working towards ensuring binary data compatibility across its platforms for multiple years. The rules for how data is arranged in memory is essentially identical across current ARM and Intel chips Apple uses. Not to mention that many modern Apple iOS apps have been shipping as platform-independent code for a while. This makes it much easier to create software that can adapt to a target platform on demand.
Anyway, we will see. It's all just speculation. But I will be very surprised if they decide to go a difficult route and essentially integrate an iPad inside a Mac...
This isn't evidence. x86 can easily run ARM instructions as interpreted code. It doesn't work well the other way around. Apple could also do code translation - again, a lot easier going from ARM to x86, or just have different back-end targets for their compiler/linker.
The evidence of macOS on ARM will be when major software vendors leak it. Apple will contact major software providers and provide them with the porting tools and training to get the ball rolling and IT WILL LEAK. Then you can expect macOS on ARM a year or more later.
The evidence of macOS on ARM will be when major software vendors leak it. Apple will contact major software providers and provide them with the porting tools and training to get the ball rolling and IT WILL LEAK. Then you can expect macOS on ARM a year or more later.
You mean like the “full version” of Photoshop already demoed and slated for release on IOS? Is that what you mean, because its already happening. And dont think the rest of Adobe suite isnt being worked on and coming next. These companies have to sign huge NDAs that if leaked have to pay enoumous fines and penalties. Trust me they make sure things dont get out.
And the first ARM Macs will have both Intel and ARM so “legacy” programs will still work fine along with newer ones that use ARM like Apple Arcade and other select Apple software to start with. Its not going to be an overnight transition. When Apple transitioned to Intel years ago they switched on the fly at the OS level, now Macs will have both Intel and ARM hardware and applications can run on whichever they are nativly complied for.
No.
Porting Photoshop to iOS is not the same thing as porting it to macOS on ARM.
Everything leaks. It may leak in a resume or a job interview where you, as a developer, have to talk about the work that you're doing, to a prospective employer. Or you may ask a friend about a development problem that you're having. It could be leaked by Apple employees, third-party software developer employees, third-party contractors, etc. It's just the nature of people.
I've been porting enterprise software since the 1980s working on lots of different chip architectures and operating systems. I know about the various forms of porting, temporary solutions, etc. I remember running FX!32 that did interpreting and code-translation on the fly so that Windows could run on non-x86 hardware. I'm working on a major port right now which is a royal pain in the ***.
Here's a question for you: how do you port AVX-512 machine code?
No, the T2 is nothing to do with this. Its a security-focussed chip that handles Touch/Face ID, secure boot and acts as an (encrypted) controller for solid-state drives. Letting it run application code would actually be spectacularly stupid from a security point-of-view.
The fact that it includes an ARM processor is neither here nor there. The typical modern Mac or PC probably already includes several ARM processors in keyboards, SSD controllers and other gizmos - they're popular as embedded processors. They're not there to run application code.
I quite agree that its feasible we'll soon see an ARM-based Mac - because of general industry interest in ARM (MS already has an ARM version of Windows) and Intel's difficulties in keeping up its release schedule. Obvious target would be the 12" MacBook which is overdue an update and not targeted at the sort of users who'll worry about Boot Camp or pro video software. Stick MacOS on an iPad Pro, slap a trackpad in the keyboard case and, even if you don't believe the benchmarks that say A12X is as fast as a Mac Pro, its going to give the 12" MB a run for its money.
...but that's still speculation and Apple Arcade just isn't evidence.
If Apple is going ARM, the next step would probably be a pre-announcement at a WWDC and a developers-only prototype product 6 months or so before any real product launch. (Followed by the departure of 50% of MR readers if Apple is going to use ARM as an excuse to lock down MacOS to iOS levels).
I generally agree with what you wrote.
I remember doing ports when Windows went x64 Beta with the new x64 AMD chips. I was the first person in the world to port Thundebird (the email client) to Windows x64 and the second to port Firefox. If you think ports are easy, try doing that on a project with 30 million lines of code. And this is on the same operating system, same development tools, same OS calls, mostly the same chip architecture. Assembler code and generated machine code are an absolute headache, even when you have the same architecture but 64-bits vs 32-bits. x64 to ARM is more work because of the different ISAs.
Not really. T2 and the host system have limited communication channels and while T2 indeed runs it’s own OS it’s resources are not plenty.
What you are talking about is giving the chip it’s own graphical capabilities and synchronizing that with the host OS. A completely different beast. Not to mention that letting third party apps run on a processor that handles security of all things is a terrible idea. To have a separate iOS hardware subsystem, Apple would need to put an iPhone/iPad CPU/GPU on the logic board in addition to everything else. It’s crazy engineering effort for little to no benefit.
There are a lot of people looking for jobs where I'm working and they print out their resumes in the printer room and you can see them on the table when they don't immediately pickup their printouts. Other people picking up their printouts take all of the printouts from the output tray and have to arrange them on the table by employee-id so you can see a bit of what people are printing.
I mentioned this to my manager yesterday as we're looking to hire someone to replace me.
[doublepost=1554386750][/doublepost]
It would be funny if they charged more for this device with some clever advertising.
Great explanation. I'm not knowledgeable of the intricacies of computer engineering.
Haha, Im facinated that your response to this poster not knowing engineering was to send him links to enroll in engineering classes at MIT. Its very common that individuals admit they don’t know something, nobody knows everything. Do you suggest people take classes in every situation? For example if someone says they dont know how to bake a cake is your first suggestion to get a culinary degree? I promise Im not trying to be a smart azz. Rather Im super facinated by your response to this persons post admitting he doesnt know engineering, like most people. On the other hand maybe you were suggesting instead of going through life not knowing its better to be proactive and learn? Which I agree with.
I believe that OCW has videos of the online courses and you can just watch the videos without doing any studying or reading the handouts or the textbooks. The first video in the base EE course is very instructive about abstraction and how we build things from physics to applications and it's a stunning presentation that covers physics to what the user uses. It is an incredibly compact way of presenting things which appear to be magic.
You don't need to know much about physics, operating systems, compilers and networks to get the general idea. In fact you don't even need to watch the rest of the videos in that course. But you can, for fun.
I did say "...but the problems are likely to be with big MacOS applications with loads of legacy code, ported Windows code, third-party plugins etc. (Office, Adobe CS, Logic Pro...)" and Firefox/Thunderbird wouldn't look out of place on that list.
Calling AMD-64 and IA-32 (or whatever that code was originally written for) "the same architecture" is, let's say, stretching the point. 32 vs 64 bits is rather a biggie - and also irrelevant here since 32 bit code won't run on either iOS or the next version of MacOS. There's no "endian-ness" problem with ARM vs Intel, either.
...and its 2019. Machines are faster, OSs are far better designed (the pox upon the OS world that was Windows 9x and the collapsing wreck of MacOS 9 are long gone) and include more platform independent frameworks. We're also in a more platform-independent world c.f. the 'who cares as long as it works on Wintel' attitude of the 90s/00s. "Assembler code and generated machine code" should be far rarer today than in "ancient" code written for the Windows 95 era. (Is it even allowed on iOS?). I'm not saying that it will be a non-job, but "porting" modern written-for-MacOS apps to ARM should generally be a far simpler job than even the PPC to Intel port in 2005 - or even the recent 32 to 64 bit port. iOS Apps to MacOS will be exactly as difficult as converting them to use the Marzipan API.
And those are the applications that you want out there at launch time. I've sat in on development meetings at Mozilla. If Apple asks for Mozilla to port to macOS on ARM, do you think that it stays a secret? On an open source code base? It gets out into the public.
AMD-64 or x86-64 vs x86 - it's the same hardware. But with two similar ISAs on the same chip. I think that PPC did the same thing - my memory is fuzzy but I think that it had 32/64 bit modes, maybe on the G5. I do recall doing work on 64-bit images - and maybe they didn't run on the G4s. Mozilla, at the time, was fairly portable running on 32-bit systems and 64-bit systems. You had VAX, Alpha, Sun systems, along with Linux, PPC 64-bit, HP-UX. So most of the 32/64 switches were already there. But you had Windows-specific code that may not have been well written. You have assembler code as well. You had plugins and the only way to get them to work is to wrap them in a container, perhaps in a separate process. You had plain porting bugs and you had the build tools. We were running on Cygwin back then and support for 64-bit wasn't terribly smooth at the time. They did not have generated code at the time but they do now with the Javascript JIT engine put in by Andreas and overseen by Brendan. I think that all of the main browsers do this now for performance reasons.
I've been reading stories and speculation that Apple would build MacBooks based on ARM since 2008. It comes out every year in the spring. It's like Charlie Brown kicking the football. Forgive me for being a little skeptical. When it happens, we'll know about it. Until then, who cares?
Which is why I have already said in a previous posting, if it happens, Step #1 will be an pre-announcement at a WWDC followed by the release of developer hardware - as happened with the PPC to x86 move. Or, the first ARM machine will be a 12" MacBook replacement, or an iPad running MacOS, for customers who are happy with Pages, Keynote etc.
Oh, it gets even worse. Instruction sets like AVX and AVX-512 are like entirely new CPUs alltogether...
Yeah, I mentioned AVX-512 in an earlier post. What would be cool is if Intel could implement Huffman block compress and decompress (and other block multimedia operations) operations. I haven't seen a vector implementation for either yet.
No problem.
Bear in mind that this particular thread started out with people talking about ARM Macs being needed to run iOS Apps and Apple Arcade games. So the initial argument was about the difficulty of porting iOS Apps from ARM to Intel - and given the App Store restrictions and the lack of ancient legacy apps that will mostly be a tick-the-box-in-XCode job compared with the substantial UI design and Application Framework differences (which is where Marzipan comes in). For Apple Arcade that's a non-issue since the games have been written to be multiplatform.
The wider issue of moving Macs to ARM is much messier - it should be a lot easier than some people make out, considering that Apple have pulled off processor moves twice before - and even c.f. 2005 modern Mac software should be - on average - a lot less hardware-specific. That doesn't mean that it could happen overnight and the two ways that Apple could stuff it up would be (a) moving to quickly and letting the Intel Macs fall obsolete before key software has been ported (b) using it as an excuse to lock-down MacOS. The casualties are going to be virtualisation of x86
Ugh. I'll pass. However, if you've successfully done that sort of port on a bloat-monster like Firefox (does that include some sort of JIT Javascript compiler?) on your own then - although I'm sure it wasn't easy - it is a modest job by modern software development standards and shouldn't be a deal-breaker on a commercially viable software product.
The ARM Windows version of Firefox is in hand, BTW - and while that's not the same as a port to a hypothetical MacOS/ARM platform it does mean that many of the processor-related issues will be identified - and if the code is so badly organised that little of that work is 'transferrable' then maybe it deserves to die. Most of the big open source projects already run on ARM (and various other architecture) so, again, although porting to ARMintosh won't be a no-brainer, most of the issues will have been flagged and solved. UNIX-type operating systems have always had a cross-platform ethos so code tends to be written more with porting in mind c.f. the Wintel monoculture of the 80s/90s/00s.