ARM based MacBook Pro discussion [merged]

[Falhófnir]

I think the Air is certainly the prime candidate for ARM this year, they've already set it up with just one CPU option (i5), and as they make quite a bit of cash from charging big for CPU upgrades that cost them cents on the dollar I wonder if this isn't a result of Apple setting the Air up for a future where there's only going to be one CPU option available?

Additionally, while I think people are largely blowing the software problems out of proportion (look at what's just been thrown on the bonfire with Catalina anyway) this is even less a consideration for an Air that's more likely to be used solely for web and office applications - both of which are fully within Apple's gift to implement and make run as well as they want (Safari/ iWork suite).

 

[ctyrider]

I think the Air is certainly the prime candidate for ARM this year, they've already set it up with just one CPU option (i5)

You honestly think Apple is going to stick an ARM CPU in a traditional laptop like Air, and call it a day? What exactly would be the point of that? And what would be the real benefit to the end user? A few extra hours of battery (my Air battery already lasts me all day).. at the expense of a crippled Chromebook-like laptop, that doesn't run vast majority of native MacOS applications??

It would be pure insanity for Apple to go down that path. I do not see it happening, not this year, not ever.

 

[pshufd]

You honestly think Apple is going to siick an ARM CPU in a traditional laptop like Air, and call it a day? What exactly would be the point of that? And what would be the real benefit to the end user? A few extra hours of battery (my Air battery already lasts me all day).. at the expense of a crippled Chromebook-like laptop, that doesn't run vast majority of native MacOS applications??

It would be pure insanity for Apple to go down that path. I do not see it happening.

It’s the Great Pumpkin.

 

[PeterJP]

https://www.macrumors.com/2020/02/24/mac-apple-designed-processor-2021/

It's got a date! 1H 2021. My guess is it will be a new macBook (plain vanilla, no Air or Pro) targeted at mobile office users. On the other hand, that would be very similar to Microsoft's ARM approach and knowing how different Apple wants to look compared to Microsoft, it might be something completely different altogether.

 

[ctyrider]

https://www.macrumors.com/2020/02/24/mac-apple-designed-processor-2021/

It's got a date! 1H 2021. My guess is it will be a new macBook (plain vanilla, no Air or Pro) targeted at mobile office users. On the other hand, that would be very similar to Microsoft's ARM approach and knowing how different Apple wants to look compared to Microsoft, it might be something completely different altogether.

It's going to be different, alright. Apple ARM "laptop" will be nothing like a MacBook. It will almost certainly run a future version of iPadOS, thus getting instant out of the box support by a vast base of iPadOS apps.

As I keep saying - Apple is not going to just slap an ARM processor in a classic MacBook running macOS and call it a day. macOS computers are going to remain on Intel, until the entire platform is sunsetted.

For those who don't believe me - just look at the latest Information report about an upcoming iPad keyboard with a trackpad. This is one step towards an Apple "convertible" - and you better believe it's going to be running iPadOS.

 

[sublunar]

It's going to be different, alright. Apple ARM "laptop" will be nothing like a MacBook. It will almost certainly run a future version of iPadOS, thus getting instant out of the box support by a vast base of iPadOS apps.

As I keep saying - Apple is not going to just slap an ARM processor in a classic MacBook running macOS and call it a day. macOS computers are going to remain on Intel, until the entire platform is sunsetted.

For those who don't believe me - just look at the latest Information report about an upcoming iPad keyboard with a trackpad. This is one step towards an Apple "convertible" - and you better believe it's going to be running iPadOS.

It would be a significant step for iPadOS for sure since at the moment since mouse support for the iPad appears to be an accessibility feature rather than a mainstream OS level thing.

Perhaps it'll be app level support feature in the next version of iPad OS.

 

[ctyrider]

Perhaps it'll be app level support feature in the next version of iPad OS.

Yes, it would have to be, if the Information report about iPad trackpad/keyboard is accurate. The whole thing is a huge tell about where Apple is heading with their future vision for mobile computers.

 

[HappyIntro]

Would an ARM-powered laptop be any more resistant to Viruses, Malware, etc., than current Intel-powered models? I'm thinking it wouldn't be any more resistant, but I'm sort of ignorant of the underlying mechanisms behind those threats.

 

[ascender]

Would an ARM-powered laptop be any more resistant to Viruses, Malware, etc., than current Intel-powered models? I'm thinking it wouldn't be any more resistant, but I'm sort of ignorant of the underlying mechanisms behind those threats.

No, not really and macOS obviously has various built-in processes to minimise the thread from viruses & malware anyway.

There's clear advantages to Apple having control over what chips go in their product and you only have to look at the performance of the recent iPads and iPhones to see the potential. Interesting times ahead.

 

[PeterJP]

As I keep saying - Apple is not going to just slap an ARM processor in a classic MacBook running macOS and call it a day. macOS computers are going to remain on Intel, until the entire platform is sunsetted.

Well, I believe it would be entirely possible to do a Rosetta style project to move mac to ARM. But unfortunately (because I like exciting big projects), I think your approach is more realistic. Realistic being a key word since the swashbuckling days of Jobs are over.

But I do not agree the announcement of a trackpad cover for an iPad equals the end of the mac platform...

 

[Unregistered 4U]

just look at the latest Information report about an upcoming iPad keyboard with a trackpad.

The first thing I thought when reading that was, basically the current keyboard with a touch sensitive surface. You press down on the space bar for a second, then run your hands over the keys, the same way as with the software keyboard. The current keyboard isn’t flat, but with smart software, a touch could be tracked across the key tops/edges, and plotted to the screen. Accurate enough for insertion point moving, BUT it’ll be interesting to see what they actually do

 

[thedocbwarren]

That can only happen if they open up their dev tools. You still have to write the software for the platform. Yes they can cloud this, but not the best experience.

Well, I believe it would be entirely possible to do a Rosetta style project to move mac to ARM. But unfortunately (because I like exciting big projects), I think your approach is more realistic. Realistic being a key word since the swashbuckling days of Jobs are over.

But I do not agree the announcement of a trackpad cover for an iPad equals the end of the mac platform...

 

[Maximara]

Microsoft has a huge albatross around its neck in the form of legacy applications, including a vast amount of ancient in-house written software in the corporate market - if MacOS is nicer than Windows that's a big part of the reason. They've faced a massive uphill struggle to get rid of Windows XP - and many of the faults in that (e.g. everything running with Admin rights) were because it had to run apps written for DOS and Win3.1 and Win9x ...and really old x86 code, even in C, can be really non-portable, since early DOS/Windows wasn't properly 32 bit and those OSs didn't have such extensive hardware-independnet frameworks.

Heck, Microsoft has tried to make an ARM version of their WindowsOS fly...and it has worked about as well as a plane made out of concrete. Yes Windows is really Balkanized now though Windows 7 is their main problem now (23.18%) But if Microsoft with their huge markshare can't make ARM work on a desktop/laptop then what hope does Apple have?

Apple don't really have the corporate drag-anchor and can be much more flexible - has already completely switched OS once (Classic MacOS to son-of-NextStep-aka-OS X) and processor twice (68k to PPC, PPC to Intel - thrice if you want to count 6502 to 68k). Over the last year, they've thrown 32-bit support under a bus and declared OpenGL obsolescent (I'm sure MS dream of being able to do that). Dropping 32 bit in itself has probably cleared out a lot of the "dead wood" that would hamper an ARM switch.

But those were two different transfers via two totally different methods. Rosetta lasted until Apple ended supported for classic and the only way they could the PPC to Intel switch was to have programmers write universal binaries (ie PPC and Intel code in the same program. What fun...not).

More over thanks to Apple having refurbished Macs going back as far as 3 years that meaning that Intel code will have to be supported 3 years after the last Intel Mac is shipped.

Must say the isolation that programs are supposed to have from the hardware is not always realized. Programmers take shortcuts and those shortcuts tend to bit the consumer in the rear end.

Rumors are not facts. There is nothing in this that we haven't seen/read yet.

This times a billion.

"Axios today confirmed Bloomberg's reporting"

"So says a report from Bloomberg"

"Bloomberg has shared a new report that says the company could make the change within the next two years."

"The story comes from Bloomberg"

The same organisation that published "the great hack" - which has been refuted by basically everyone including their own sources, and continues to stand by the article.

Sure, sounds convincing.

'Keep saying it long enough and loud enough and they will believe.' - whole foundation of the Big Lie concept. If we had multiple independent sources saying this rather then everybody repeating what one source, whose reputation seems to be a total joke, said I would be far less skeptical.

 

[nicho]

Heck, Microsoft has tried to make an ARM version of their WindowsOS fly...and it has worked about as well as a plane made out of concrete. Yes Windows is really Balkanized now though Windows 7 is their main problem now (23.18%) But if Microsoft with their huge markshare can't make ARM work on a desktop/laptop then what hope does Apple have?

Huge marketshare in software/OS, relatively small slice of hardware. If anything this would give Apple an advantage twice over (fewer concerns about legacy support and - officially - 100% share of the hardware market for their own OS, no reliance on others).

However, I still have considerable doubts.

 

[AlanShutko]

One difference between Microsoft and Apple is that Apple is probably the manufacturer shipping the highest performance ARM cpu in the highest volume today. They are in a unique position by controlling the software and hardware and able to make them work together. For an example, look at the tagged pointer representation they implemented for Objective C when deploying their 64-bit ARM. They also have a history of aggressively dropping support for legacy stuff.

On the other hand, macOS has way more diversity of software than iOS. MacOS has developers sharing code between Windows and Mac builds. It has code bases that have been gradually updated for decades. It has apps which exist outside the App Store walled garden and have different access to OS features. I remember that the 64-bit transition was a bit rocky for Adobe and took several releases: would ARM cause the same problems?

I dunno. I think it's possible to move everything over and Apple has more experience switching CPUs than anyone. But there's a lot of devil in the details.

 

[Maximara]

On the other hand, macOS has way more diversity of software than iOS. MacOS has developers sharing code between Windows and Mac builds. It has code bases that have been gradually updated for decades. It has apps which exist outside the App Store walled garden and have different access to OS features. I remember that the 64-bit transition was a bit rocky for Adobe and took several releases: would ARM cause the same problems?

It not just Windows but a huge library of gcc compilable (and already compiled for Intel Mac) Linux code out there that is totally functional with Darwin as is. MacPorts is your friend.

If Apple does put out a ARM laptop/desktop I just hope they do not do a really really dumb thing like the LCII.

For those of you who are not familiar with this 'were they thinking?' design FUBAR let me enlighten you.

The LC had 2 MB on the motherboard and could be upgraded to 10 MB (two 4 MB RAM chips) and you could not mix ram sizes (ie a 4MB and 2 MB simply wouldn't work - you either got 6 or 4 MB total, if it booted up at all) thanks to the way the ROM worked. The ROM had another aspect - it couldn't see more then 10 MB.

The LCII was effectively an LC with 4MB on motherboard but retained the LC's ROM. I imagine those of you paying attention have already seen where this is going and are thinking 'Who thought that was a good idea?' For those of you not seeing it, thanks to the way the LC's ROM worked you could only put in two 4 MB RAM chips to max out the machine...which effectively wasted 2 MB of RAM. The ROM couldn't see it so it could not even be used for video RAM.

The LCIII did what should have been done in the LCII...Apple put in a ROM chip that could actually see 12 MB of RAM.

 

[theluggage]

But if Microsoft with their huge markshare can't make ARM work on a desktop/laptop then what hope does Apple have?

First, as @nicho said, Apple control the hardware. Microsoft can't say 'As of 2021 all new PCs will be ARM based' - Apple can and has successfully done the equivalent twice in the past. Windows has always been tied to incremental improvements of the same old 8086 processor. Remember Windows for PowerPC, Alpha, MIPS, Itanium, ARM (at least 1 previous attempt)... they went well.

Second, Apple doesn't have anything like the same legacy software issue.

A couple of weeks ago I had a query about some software I wrote in the 1990s - I fired up Windows 10 (32 bit edition - still supported) , dug out a binary, double clicked and - bingo! Ran perfectly except it was a tad 'soft focus' on a 4k screen. Tried another, more complex one with DLL back-end and stuff - worked fine. 20+ year-old binaries running 'out of the box' - that's the expectation, nay requirement, of the huge corporate PC-using sector on which MS relies. On a modern Mac, you're lucky if a 5-year-old binary will run, and 20-year-old software would need a major re-write from 'classic' to 64-bit OS X Cocoa. There just isn't the same expectation/reliance on old apps as in the PC world.

But those were two different transfers via two totally different methods. Rosetta lasted until Apple ended supported for classic and the only way they could the PPC to Intel switch was to have programmers write universal binaries (ie PPC and Intel code in the same program. What fun...not).

You've got your facts mixed up.
Classic (10.0 -10.4) was a compatibility layer that let Mac OS 9 and earlier code run on Mac OS X. It was written for PPC but since it could run the 'classic' 68k emulator it also worked with 68k apps.
68k emulator (7.1.2 to 9.2.2, then as part of 'classic') was an emulator that let 68k code run on PPC.
Rosetta (10.4-10.7) was an emulator (or, more precisely, a binary translator) that let PPC code run on Intel.

Both the 68k-PPC and PPC-to-x86 transitions went exactly the same way: long-term, developers had to re-compile their apps for the new processor and ship 'Fat Binaries/Universal binaries' containing both versions, but as an interim solution, and last resort for 'abandonware', there was an emulator available, which Apple supported for as long as practicable. There's every reason to believe that the rumoured ARM transition would go the same way (an x86-64 emulator/translator for ARM is a lawyer problem, not a technical one).

...and for the vast majority of code, making a Universal Binary is a matter of checking a box in XCode and re-compiling your processor-independent C/ObjC/C++/Swift code. Know what is not fun? Writing assembly code or other CPU-specific code at all so developers only do it when absolutely necessary - even things like drivers can be substantially written in C.

In fact, the 68k-to-PPC and PPC-x86 transitions had it worse - the older and slower the processor and the less sophisticated the OS in terms of abstracted graphics/sound/acceleration frameworks the more likely developers are to resort to assembly language or other hardware-dependent code. Then the PPC-to-x86 transition meant switching from big- to little-endian mode (the order in which bytes are stored in 16-bit or longer numbers) which can impact on data and file formats even in high-level languages. The switch to 64 bit - now done - will have been a bigger deal for many applications than switching from one 64-bit/little-endian CPU (x86-64) to another (arm64).

The Mac OS Classic to Mac OS X transition was a different - and far more impactful - change to a completely different, non-source-code-compatible OS that required all applications to be significantly re-written. The 'carbon' interim application framework helped avoid having to re-write UI-code from scratch but it certainly wasn't 'tick box' - in fact, for many, it was 'learn a whole new set of developer tools' (Metrowerks->XCode).

Basically, any application that has made it through 3/4 such 'extinction events' should be in pretty good shape to switch to ARM with modest effort, and newer software written to Apple's modern guidelines should be a breeze. Yes, of course, there will be exceptions (esp. with obscure pro-app plugins) but all this has happened before and can happen again.

The one fly in the ointment this time round, that didn't exist before, are the users who rely on virtualising or 'bootcamping' x86 operating systems. That may be a sacrifice that Apple is prepared to make...

This times a billion.

Sure - its just a rumour. Nothing is certain. That doesn't make re-heating the same discredited arguments that were used against the PPC and Intel switches valid.

 

[sakagura]

AMD Zen side channel vulnerabilities discovered.

New AMD Side Channel Attacks Discovered, Impacts Zen Architecture (AMD Responds)

AMD processors from 2011 to 2019 impacted

www.tomshardware.com

So we hope an ARM based Mac doesn't have these kind of flaws. It's extremely hard to design any kind of chip or software without a hole somewhere.

 

[nicho]

First, as @nicho said, Apple control the hardware. Microsoft can't say 'As of 2021 all new PCs will be ARM based' - Apple can and has successfully done the equivalent twice in the past. Windows has always been tied to incremental improvements of the same old 8086 processor. Remember Windows for PowerPC, Alpha, MIPS, Itanium, ARM (at least 1 previous attempt)... they went well.

Second, Apple doesn't have anything like the same legacy software issue.

A couple of weeks ago I had a query about some software I wrote in the 1990s - I fired up Windows 10 (32 bit edition - still supported) , dug out a binary, double clicked and - bingo! Ran perfectly except it was a tad 'soft focus' on a 4k screen. Tried another, more complex one with DLL back-end and stuff - worked fine. 20+ year-old binaries running 'out of the box' - that's the expectation, nay requirement, of the huge corporate PC-using sector on which MS relies. On a modern Mac, you're lucky if a 5-year-old binary will run, and 20-year-old software would need a major re-write from 'classic' to 64-bit OS X Cocoa. There just isn't the same expectation/reliance on old apps as in the PC world.



You've got your facts mixed up.
Classic (10.0 -10.4) was a compatibility layer that let Mac OS 9 and earlier code run on Mac OS X. It was written for PPC but since it could run the 'classic' 68k emulator it also worked with 68k apps.
68k emulator (7.1.2 to 9.2.2, then as part of 'classic') was an emulator that let 68k code run on PPC.
Rosetta (10.4-10.7) was an emulator (or, more precisely, a binary translator) that let PPC code run on Intel.

Both the 68k-PPC and PPC-to-x86 transitions went exactly the same way: long-term, developers had to re-compile their apps for the new processor and ship 'Fat Binaries/Universal binaries' containing both versions, but as an interim solution, and last resort for 'abandonware', there was an emulator available, which Apple supported for as long as practicable. There's every reason to believe that the rumoured ARM transition would go the same way (an x86-64 emulator/translator for ARM is a lawyer problem, not a technical one).

...and for the vast majority of code, making a Universal Binary is a matter of checking a box in XCode and re-compiling your processor-independent C/ObjC/C++/Swift code. Know what is not fun? Writing assembly code or other CPU-specific code at all so developers only do it when absolutely necessary - even things like drivers can be substantially written in C.

In fact, the 68k-to-PPC and PPC-x86 transitions had it worse - the older and slower the processor and the less sophisticated the OS in terms of abstracted graphics/sound/acceleration frameworks the more likely developers are to resort to assembly language or other hardware-dependent code. Then the PPC-to-x86 transition meant switching from big- to little-endian mode (the order in which bytes are stored in 16-bit or longer numbers) which can impact on data and file formats even in high-level languages. The switch to 64 bit - now done - will have been a bigger deal for many applications than switching from one 64-bit/little-endian CPU (x86-64) to another (arm64).

The Mac OS Classic to Mac OS X transition was a different - and far more impactful - change to a completely different, non-source-code-compatible OS that required all applications to be significantly re-written. The 'carbon' interim application framework helped avoid having to re-write UI-code from scratch but it certainly wasn't 'tick box' - in fact, for many, it was 'learn a whole new set of developer tools' (Metrowerks->XCode).

Basically, any application that has made it through 3/4 such 'extinction events' should be in pretty good shape to switch to ARM with modest effort, and newer software written to Apple's modern guidelines should be a breeze. Yes, of course, there will be exceptions (esp. with obscure pro-app plugins) but all this has happened before and can happen again.

The one fly in the ointment this time round, that didn't exist before, are the users who rely on virtualising or 'bootcamping' x86 operating systems. That may be a sacrifice that Apple is prepared to make...




Sure - its just a rumour. Nothing is certain. That doesn't make re-heating the same discredited arguments that were used against the PPC and Intel switches valid.

I wonder how hard it would be to design an ARM system with a low power x86 chip alongside? Nothing fancy, but enough to make it possible to run things without emulation.

Aren’t they essentially doing the opposite now with the T2?

 

[Stephen.R]

I wonder how hard it would be to design an ARM system with a low power x86 chip alongside?

They did this (well not the Arm part) in the 90s with "DOS Compatibility cards" - http://www.edibleapple.com/2009/12/...-look-back-at-apples-dos-compatibility-cards/

Aren’t they essentially doing the opposite now with the T2?

I still believe any kind of "Mac on Arm" machine is essentially going to either:
- pair an Arm + x86 (I don't see it being AMD but maybe they're more willing to do custom silicon to support it) in some way; or
- essentially just expand the current duties the T2 has, so macOS still boots on Intel (or AMD) but a heap of extra stuff is offloaded to the T3/T4/etc, perhaps with the ability for an app to ship an Arm binary to run on that chip for low-power work.

 

[leman]

I wonder how hard it would be to design an ARM system with a low power x86 chip alongside? Nothing fancy, but enough to make it possible to run things without emulation.

Why would you want to do something like this? I can’t imagine the performance of such hybrid system being anything but terrible, and it is likely to be very expensive in terms of footprint and energy consumption.

A much simpler - and more practical solution - is to recompile the x86 code to ARM and just run it. Apple has been backing tech that is able to do it for years now. Binary data alignment is identical between modern ARM and x64, so that’s the biggest challenge done. The only other significant issue I can see is that x64 has instructions (mostly SIMD) that don’t map well to ARM. But it can be solved with custom extensions - and Apple makes their own silicone.

Aren’t they essentially doing the opposite now with the T2?

T2 is mostly about security and power savings. It’s not capable of running general purpose apps and it would defeat it’s purpose if it could.

 

[theluggage]

wonder how hard it would be to design an ARM system with a low power x86 chip alongside?

1994 called and want their idea back: http://chrisacorns.computinghistory.org.uk/Computers/RiscPC600.html

I have one mouldering in my cupboard - I'd fish it out and fire it up except I'd probably be deafened by the sound of exploding capacitors...

Previous Acorn ARM systems had the choice between software x86 emulation and full-sized expansion cards with, essentially, a complete PC sans graphics - but the RISC PC reduced that to a small card with an x86 and a 'glue logic' chip that effectively acted as a hardware accelerator for the software emulator.

One neat thing was that, apart from running Windows (3.1) at acceptable speeds, there was a utility that let you use the x86's floating-point unit with the ARM (which didn't have a FPU in those days - not an issue now). The less neat thing was, what with the cost of small runs of custom electronics, you could get a complete (if cheap'n'cheerful) PC for the price of the more powerful 486/586 cards (there was a basic one with, if memory serves, an IBM 386 clone, that was more reasonably priced).

Thing is, today, you could probably just get a compact PC and virtual-desktop to it.

- essentially just expand the current duties the T2 has, so macOS still boots on Intel (or AMD) but a heap of extra stuff is offloaded to the T3/T4/etc, perhaps with the ability for an app to ship an Arm binary to run on that chip for low-power work.

Except that fails to deliver several of the major advantages for switching to ARM: independence from Intel and their erratic release cycle, the ability to have most of the guts of a MBA/MB on a single chip, more cores for the same thermals & size on the MBPs and desktops and power saving across the board - not just specially coded apps.

I agree that there's no certainty this is going to happen - we could be talking custom AMD chips, Intel chips with AMD graphics. ARM chips with AMD graphics, Intel chips with A-series graphics, mangled stories about the T3 chip, Macs with iPads in the lid or - entirely possible - Intel business as usual but with Apple getting a better deal as a result of reminding Intel that other CPUs are available...

 

[Stephen.R]

Except that fails to deliver several of the major advantages for switching to ARM:

Everything is a trade off, and it entirely depends on what "goals" any hypothetical project to use ARM based processors in a Mac (in some fashion 'greater' than the T2 is now) has.

 

[Falhófnir]

Why would you want to do something like this? I can’t imagine the performance of such hybrid system being anything but terrible, and it is likely to be very expensive in terms of footprint and energy consumption.

A much simpler - and more practical solution - is to recompile the x86 code to ARM and just run it. Apple has been backing tech that is able to do it for years now. Binary data alignment is identical between modern ARM and x64, so that’s the biggest challenge done. The only other significant issue I can see is that x64 has instructions (mostly SIMD) that don’t map well to ARM. But it can be solved with custom extensions - and Apple makes their own silicone.



T2 is mostly about security and power savings. It’s not capable of running general purpose apps and it would defeat it’s purpose if it could.

I agree that (dual CPUs) seems a really messy and massively overcomplicated solution. A well managed transition that makes porting software as easy as possible but puts sufficient pressure on developers to commit to the new platform is going to be the way through this if they're doing it. Keep key x86 machine options around for long enough that those who want or need to can avoid any pain with abandonware that's not going to be updated, but make it clear Arm is the future of the platform and developers need to be focusing their efforts on that going forward.

What people forget is that regular MacOS updates break compatibility with old software that's no longer updated anyway. I'm not even talking about big conscious efforts like Catalina dropping 32 bit, either. Just all the little cumulative tweaks slowly erode away at the smooth functioning of old software if it isn't actively maintained.

 

[sakagura]

You don't need to worry about these x86 to ARM translations. Apple always has a separate fork of Mac OS/macOS during the transitions. They start working on these for a few years before they announce anything. Upon release you will have Universal binaries just like the PPC to Intel transition and the 68000 to PPC transition (they were called FAT binaries back then).