Why Apple Will Switch to ARM-Based Macs (2014)
mattrichman.net
mattrichman.net
Some key take away:
- A lot of people got it wrong with the bet on Intel.
- 2 people that said it will take 5 years were right.
- Suggestion to use Rosetta was right.
- Indicator for fan less Macbooks was right.
It's easy to doubt but it actually takes effort to form educated guesses about the future.
2015 is the year both the (Intel) 12” MacBook and the first iPad Pro were released.
These we also both entirely new form factors for Apple (and both roughly the same size).
On the Intel front, Apple saw how underperforming, short lasting battery and hot the 12” MacBook was.
Then they saw how performant, long battery lasting and cool their iPad (ARM chip) was.
This became an easy decision for Apple to ditch Intel when they saw how much better their own iPad Pro was relative to the 12” Intel MacBook.
I sure hope they saw. They designed, built and sold the things.
Would be hard to miss those issues during their development and testing, wouldn't it?
It's not like Apple didn't know what they were selling.
Not to mention tons of people love them...
What did you expect would happen?
It would be like Apple putting the chip from the Mac Studio in the Air.
They could, but those were crap.
>What did you expect would happen?
That it would be a niche due to size, but otherwise much beloved model, whose 2022 absense is still lamented? (See comments below)
Yes it was slow but really, not terrible.
It ran windows with battery life better than macOS. It was a solid form factor. Never over heated. Great for traveling with.
I miss mine.
For sure, the weakeast point of it was the processor, which had to sacrifice too much performance to stay in the thermal budget. I guess the basic design decisions for the 12" MacbBook were made when Intel still seemed to be on track for their 10nm process. But it wasn't the only caveat with its design. It had of course the horrible butterfly keybord which would plague the Apple laptops for years and 12" is the absolute minimum screen size for doing work.
I think Apple has another laptop design < 13" coming, that could be 12". The ARM processors pretty much solve the power/performance problem. The keyboard could actually be the biggest hurdle, as it increases the body thickness. But the keyboard of the new M2 Air is just wonderful, well worth whatever it adds to the device thickness. I wouldn't even be surprised, if they don't make an ultra-thin 12" MacBook but rather a 12" MB Pro, which might be slightly thicker than the Air.
Nowadays you could stick a (maybe throttled or fewer cores to get even more battery life) M1/M2 in there, add a second USB-C port, and it would be an excellent device without any of the downsides that the original version had.
That form factor with m1/2 would be awesome! Especially to use in bed cos the screen was so nice and it was so light.
I kinda wanna get an M2 Pro but I personally dislike macOS. :(
Then they saw how performant, long battery lasting and cool their iPad (ARM chip) was.
This became an easy decision for Apple to ditch Intel when they saw how much better their own iPad Pro was relative to the 12” Intel MacBook.
For those who have being using Mac since the PowerPC days all have used this argument against X86 chips. As you all know, Apple actually had to switched from RISC chips to Intel X86 chips, before they switched back to ISAs chips now. Just saying performance is not the main reason to switch chip sets.
Apple abandoned PPC after it became obvious that laptops were going to become more popular than desktops, and the G5 cheese grater Mac Pro required liquid cooling for the dual CPU chip versions.
Apple moved from Intel to ARM for the exact same reason. Intel no longer cares about pursuing high performance with a low power draw. They have returned to the Pentium 4 strategy of performance via clock speed and power increases.
https://www.extremetech.com/computing/338748-raptor-lake-to-...
If that isn't a return to the Pentium 4 strategy, I don't know what is.
Intel isn’t relying on an architecture thats about to run them into a wall like the Pentium 4’s architecture was about to, what keeping them is second is being behind on their process, and beyond that, execution.
You can argue that it's not what they "want" to be doing, but it's certainly what they are doing.
https://www.digitaltrends.com/computing/intel-raptor-lake-ma...
What you can't change is the reality of Intel's actions.
[1] implies that the M1 development started around 2008 - although you could also read it that the M1 was 5 years in development but that sounds a bit quick and also doesn't fit with [3] in 2014 - "Apple Testing ARM Based Mac Prototypes".
But there doesn't seem to be any other direct corroboration of the 2008 date that I can find.
[1] https://www.youtube.com/watch?v=4oDZyOf6CW4 via [2] [2] https://news.ycombinator.com/item?id=31778257 [3] https://www.macrumors.com/2014/05/25/arm-mac-magic-trackpad/
Around what time? 2015?
Maybe I could have been more clear in my original post but 2015 was the year the iPad Pro launched.
How could the “iPad Pro were getting close to Intel performance” happen in thr first version?
The very first iPad Pro was already more performant than the MacBook 12” (which also launched that same year).
Whenever Tim Cook was asked, why pretty much up until maybe a few months before the apple silicon announcement, he said there weren’t any plans to switch the mac to arm.
see fallon.eth
some people see value in this some people perhaps not
Also if I want to trade anonymously there is always cash ( as least for now ), which is a simple, well understood, near universally accepted mechanism.
There are niches where decentralized banking is useful - but they are niches - and many of them are associated with dubious activity.
On top of that the current tech plaforms simply don't scale - the cost of replacing simple trusted parties with technology is huge.
for most people in the US or the world? i think everywhere banks rank amongst the most disliked institutions
Which would imply that people love banks and want them to be even more powerful.
However I do think it's a bit harsh to call these things a scam - I mean take the art market itself - value is entirely subjective - doesn't mean it's a scam ( though scamming things happen in the normal art market to try and inflation prices ).
The question you have to ask yourself is:
Are you buying the NFT as an investment - because you think other people will value it, or are you spending the money because you are quite happy to own that thing forever and never sell - ie the value is to you.
I'd argue if you are doing the former you are more likely to be 'scammed' than the latter.
Being wrong once is one thing, but HN commentary seems consistently wrong on a whole litany of topics. The biggest source of bad hot takes seems to be something new/different. HN seems to be consistently conservative.
It’s a shame because I used to think that i would gain some insight on future trends from the fact that a lot of the people who comment here are in tech, but now I’m not so convinced.
i think that's harsh. why would you even expect an aggregate sentiment of hn to indicate where to invest one's money. on the other hand it might be worth pointing out that y combinator supports plenty of blockchain projects
I5/i7's were great at that time
If you're getting hints that your chip vendor is not aligned then you better have a backup plan.
I think you got really lucky. Zen1 didn't ship until 2017 and it lagged severely behind in single thread. You had no idea what AMD was going to have.
Even AMD would tell you that they were surprise that Intel fell so far behind. They've been quoted saying this a few times.
Intel's 10nm Node (equivalent to TSMC 7nm) was suppose to ship in 2016! It didn't ship anything on the desktop using 10nm until Alder Lake in 2021. Five year delay.
Intel would have been well ahead of Zen2 in node technology. Instead, it was around 1.5 node behind.
If you made your bet purely on what was said inside AMD in 2015, you just got lucky. No one knew that Intel would be stuck on 14nm for 7 years when they were planning for 2 years.
I’m sure luck was involved (so many things could go wrong). But i tend to make money on bets based on what I hear on the fringe. AMD, Bitcoin, etc
Built this: https://insideropinion.com/
But use it for investments.
You can’t completely remove risk, but I invest in areas where insiders discuss publicly about their work. It provides insight often fundamentals lack; leaving massive potential upside.
I’m equal parts horrified and amazed. And curious what The Algorithm thinks about my ramblings.
At the time, it was hard to notice, but reviews at the time absolutely noticed the minor CPU update (https://www.theverge.com/2015/4/9/8375735/apple-macbook-pro-..., search "Broadwell"). Another funny aspect of that review: it mentions out 10+ hour battery life for the MBP as a nice, but hardly astonishing spec. 9 hours 45 minutes with Chrome was the worst case. It's amazing to think how bad the 2016-2019 MBPs were in comparison, to the point where getting back to 10 hour battery is an amazing Apple Silicon feature!
My M1 Max is amazing by comparison.
Phew. I’m glad I didn’t comment on that thread.
I didn't see this particular article but I would have agreed with it. I certainly have written many comments on similar articles (search the comments for alwillis ARM Mac for starters) explaining why such a switch to ARM was completely doable, having lived through the switch from PowerPC to Intel while working at MIT.
- Apple arcade and Apple TV will still be around but Apple has no plan/vision for gaming.
Meta will have recovered from their current issues and will be their main competitor.
I think Apple could have a big advantage because their processors could allow more powerful things in a standalone VR headset compared to the current Generation where you need a external PC for most CPU and GPU intensive tasks.
I don’t see any practicality to VRs outside some tiny niches. They make a few games more fun, some niche workloads can be done more efficiently, but they are hard to equip and first and foremost block your interactions with the real world. Sure, some contact lens futuresque thingy could improve on this as well, but how would you control that? Voice control is slow and troublesome.
So I don’t predict a huge success to VR, it will be at most something akin to an xbox’s kinect, or some wii accessory.
As far as I can tell, we have a lot of progress to make with display resolution and GPU quality before VR becomes competitive for work environments with a modern hiDPI dual display setup. Maybe it's more appealing to folks with crappy home desk setups, or people who live in cities who don't want a full desk? Ergonomics still feels like an obstacle, though.
(E.g. this for the XXI century: https://en.wikipedia.org/wiki/Isetta )
Intel is like Mike Brady with his architectural designs that all look suspiciously like his own house.
They refused to compete with themselves and kept x86 as 32 bit so they could promote Itanic, and therefore lost the lead to AMD for years (it wasn't just 64 bit - actively REDUCING instructions per clock with Netburst was... well, legendary - just in a bad way).
It just so happened that the kick in the ass Intel got from AMD came a few years before Apple needed Intel, so Intel had finally started trying enough that they had a product line that would work for Apple.
But really, is Intel suitable for low power? Could anyone seriously imagine an x86-based phone? Their one-hit wonder is only barely keeping up with AMD and ARM when Intel throws hundreds of watts at their chips and turbo-clocks the heck out of them. Even though Ryzen has been showing up Intel for years, they've floundered so long that there was practically zero chance Apple could stay with them long term.
But even in 2005, Intel wasn't necessarily good - they just happened to be the least bad right then.
It got me to buy my first Mac, at least (iMac). I figured if OSX didn’t work out I could just run Windows on it.
Maybe ironically, the new ARM Macs make me a little hesitant to buy a new MacBook because I’d be pretty much locked in to OSX (with all due respect to the Asahi folks who are doing great work - I fear Apple is going to pull the rug out from under them though.)
I don’t think so. There’s been support for “other OSs” from the start with the M line. I was actually pleasantly surprised by this.
I don’t think they will change their minds. It brings value to the platform while offering little threat.
I think we’ll be seeing a boot camp version of ARM Windows as soon as Microsoft solves its licensing issues.
> "Okay, it's been over a year, and it's time to end the nonsense speculation."
> "I have heard from several Apple employees that:"
> "1. The boot method we use is for 3rd-party OSes, and Apple only use it to test that it works, because"
> "2. It is policy that it works."
> "Hacker News peanut gallery, you can drop the BS now. It's not an "assumption" that this stuff exists for 3rd-party OSes. It couldn't "be something internal Apple uses that could go away any minute". That is not how it works, it never was, and now I'm telling you it's official."
> "And this isn't even news because @XenoKovah (who invented and designed this entire Boot Policy 3rd party OS mechanism) already tweeted about this whole thing a long time ago, but apparently it needs to be restated."
If Microsoft don't port Windows ARM to Macs, Apple might decommission the "core technologies". Even if they do, there's nothing stopping Apple from changing their mind down the lane, like they have already done on other topics, whatever the intentions of developers that developed them were.
Ultimately it leads to a discussion about the competition. When you buy an ARM based Surface, can you put Linux on it? Is Microsoft clear you can? Are they providing drivers?
> Besides, even if Apple did come out and say it, you'd still trot this nonsense out.
No. Apple saying, unofficially, they welcome Microsoft, and Apple coming out and saying they love Linux and want it, would be different. That wouldn't be any guarantee that they won't change their mind or are just hypocrites, but it would still be more meaningful than "technically it's possible, there is no official anything (only an official welcome to MS Windows, but sure, Apple absolutely want Linux on Mac to be a thing".
Between my big Linux desktop and M1 Macbook Air I'm not even sure what to do in Windows anymore. I don't need to run any Windows applications per say, and everything I do really need runs on MacOS. I still have a VirtualBox Win10 install on the Linux box, but honestly I'm not sure why, besides habit.
I don't think it's a coincidence that Intel Macs coincided with the release of Core/Core 2 Duo cpus. At the time there was nothing close to them by any metric. Remember Intel enjoyed a generational lead in foundry tech for decades.
You forget about Atom?
> ... Atom?
Indeed! The Motorola RAZR i was Atom-powered.
I then remembered why it was in the junk drawer.
The strangest part of that setup was that it used a 32 bit UEFI and a 64 bit operating system, so I couldn’t use regular Linux images. But hey, you could configure the UEFI settings using only the touchscreen!
Naturally the battery life was terrible and it lasted fewer than 12 hours in sleep mode, so it spent little time outside the junk drawer too.
Atom based phones exist, but they're not good at anything in particular.
I don't think there's any reason X86 has to use more power than ARM - it's simply not the focus of most implementations, however. As I understand it, most processors at this point are an interpreter on top of a bespoke core. Intel used to get quite a lot of praise for low power consumption back in 2012-2015 with Ivy Bridge and so on - rather coincidentally, that was also when they had a process advantage (rather like AMD and Apple today enjoy).
But from what I’ve read, having different length instructions makes extracting parallelism way harder. That’s why Apple can make such crazy wide machines.
I wonder if we'll see Intel or AMD try to make another somewhat-backwards-compatible ISA jump to keep up with ARM.
x86_32 --> x86_64 --> x86_512?
But it is much easier to simply chop off a stream of instructions at every X bits than to evaluate a portion and decide what to do later and that difference get larger the wider you go.
Variable length instructions in general do have a code density advantage, but x86 is a particularly poor example. For historical reasons, it wastes short encodings with rarely used things like BCD adjustment instructions, and on 64 bits often requires an extra prefix byte. The RISC-V developers did a size comparison when designing their own compressed ISA, and the variable-length x86-64 used more space than the fixed-length 64-bit ARM; for 32 bits, ARM's variable-length Thumb2 was the winner (see page 14 of https://riscv.org/wp-content/uploads/2015/06/riscv-compresse...).
Yes, with the complexity and transistor budgets, the disadvantages of x86 can be somewhat glossed over, otherwise they would have vanished from the market long ago, but they add a certain overhead which cannot be ignored when looking at low power applications. The efforts the CPU needs to take until it can execute the commands is higher and x86 requires more optimizations done by the CPU than RISC designs. Which today also contain a translation layer, but a way simpler one tha x86, as the assembly instructions match modern CPU structures better.
It is probably no coincidence that Intel, which had to work around the issues of executing CISC code on a modern CPU chose the EPIC design for the Itanium. Which goes beyond RISC in putting compexity towards the code generation vs. on-cpu optimizations. Too bad it didn't work out - it might have, if AMD had not added 64bit extensions to x86. While there were certainly a lot of technical challenges which were never completely solved, the processors seemed to perform quite well when run with well optimized code. Perhaps they were just one or two process generations to early. While considered large for that time, their transistor count was small compared to a modern iPhone processor. I wonder how they would perform if just ported to 7nm (the latest CPUs were 32nm).
If you'd like to see some first-hand observations about modern-ish compilers on Itanic, check out this person on Twitter who does lots of development on Itanic:
With the the A7 SoC and the A64 ISA it became clear that the ISA and Apple's Silicon design capabilities were sufficient to build SoC's that would compete with the best that Intel could offer.
However, the costs of making a transition would still be significant, maybe not in cash terms for Apple, but certainly in manpower and focus.
I suspect that it was Intel's process stumbles that led to the decision being made in the end. How many times, I wonder, did Intel promise something to Apple behind the scenes, only to fail to deliver? With the success of TSMC the opportunity for Apple's management to take more control of their own destiny would have been too compelling.
Given Tim Cook's known zeal for delivery I hesitate to think how bad things must have become later on.
Could you please expand on that? I heard they were quite distinct, e.g. sandboxing/security is done completely differently, with ios having a much more modern approach.
While pedantically it can be included in your modulo, but are they really that similar?
Therefore I strongly suspect that Apple had macOS running on the iPhone and iPad from very early on. They just did not want to release it because the UI is not suited to a phone.
If AWS Graviton or Microsoft ARM significantly grows then it might force Apple to be aligned with ARM64 but just with their own extensions. Because one of the big blockers for developers during the transition to M1 was having all of the CLI tools being available. And they were only available on day one because of demand from AWS users etc.
It really doesn’t matter. Most applications are written in non native languages like Node, C#, Java, and Python.
If you have native dependencies, even if you are on the same architecture, you’re going to run into issues developing and building packages if if isn’t the same operating system.
Simple case of building Lambdas on none Amazon Linux operating system is just add —use-containers when using the Serverless Application Model.
Other cases, I’ve had to build on Cloud 9 instances.
ARM doesn't care what you call them.
https://www.mattrichman.net/apple-and-arm-sitting-in-a-tree/
Okay.
NeXTSTEP originally ran on the Motorola 68030, then the 040. Then NeXT fully ported the operating system to run on the HP PA-RISC, Sun Sparc, Intel 486, Motorola 88000, and at least tentatively to the IBM RS/6000. This was as diverse a collection of processors as one could imagine.
When NeXTSTEP was transformed into MacOS X, it was just one more minor step to include PowerPC in that list. When iOS was developed on the iPhone, it was obvious that it was little more than a modified version of MacOS X, and primarily NeXTSTEP. Surely that's how they developed it: Apple just ported MacOS X to ARM and did development on top of it.
I guess what I'm saying is that it's not at all interesting or surprising that someone in 2014 prognosticated that MacOS X had been ported to ARM. It was clear as of 2006 that Apple had already done that. And given that NeXTSTEP had been ported to at least seven processor families prior to that, it was hardly a big deal.
It was obvious to me, knowing that MacOS is based on NeXTStep and how that ran on a bunch of different architectures—68000, Intel, Sparc, etc.
I even wrote 3 years ago here on HN (before Apple announced their transition to ARM) that I wouldn't be surprised if there were ARM-based Macs in the lab [1].
And also knowing that Apple always wants to be in control of as much of the technology they rely on as possible. After Motorola/IBM dropped the ball with PowerPC and Intel couldn't deliver the performance per watt they needed, they weren't going to fooled a third time.
I literally wrote the same thing about NeXTSTEP here on HN 3 years ago: https://news.ycombinator.com/item?id=21235236
They said exactly this at the time. The OS on the original iPhone was explicitly “OS X”, it only gained its own name several iterations later.
I've heard many answers over the years:
Mach is a microkernel, they are easier to port
NeXT never made their own hardware so they designed it that way from the start
It contained 'very little assembly'
When I think NeXT, I think the NeXTcube (1990-1993) [0], which apparently also had a predecessor in the NeXT Computer (1988-1991) [1]. NeXT made their own hardware for a solid chunk (nearly half) of their lifespan, and NeXTSTEP was originally released with the NeXT Computer [2]. It didn't even support CPU architectures other than the Motorola 68k series until 1993, around the demise of the NeXTcube! I think its ultimate portability probably has more to do with being a UNIX at its core (so a battle-tested design written in somewhat portable C) plus a user environment written in a higher-level, easier to port language (Objective-C).
[0]: https://en.wikipedia.org/wiki/NeXTcube [1]: https://en.wikipedia.org/wiki/NeXT_Computer [2]: https://en.wikipedia.org/wiki/NeXTSTEP
Though fine in 1988, NeXT's own hardware was rather under-powered for the early 90's. Their main competitor, Sun, was transitioning to their own RISC architecture (SPARC) after originally being on 68K. DEC was coming out with the Alpha. HP had moved to PA RISC. Though I digress, it's too bad NeXT never ran on the Alpha! That would've been a killer 90's setup.
The Mach-as-microkernel thing couldn't have helped portability. The Mach task, port, thread and pager abstractions seem like they'd be difficult to port, but I could be wrong.
I read at the time that NeXTStep the GUI ran faster on Solaris than on Mach, because pipes and sockets were faster than Mach ports. So I'll believe the very little assembly.
I suspect that Mach-O file format had something to do with the portability, you can put arbitrary sections in it. Some NeXT games kept image and sound "files" in a single huge Mach-O executable.
"Mach 3 (Figure B.1) moves the BSD code outside of the kernel, leaving a much smaller microkernel. This system implements only basic Mach features in the kernel; all UNIX-specific code has been evicted to run in user-mode servers. Excluding UNIX-specific code from the kernel allows replacement of BSD with another operating system or the simultaneous execution of multiple operating-system interfaces on top of the microkernel. In addition to BSD, user-mode implementations have been developed for DOS, the Macintosh operating system, and OSF/1. This approach has similarities to the virtual-machine concept, but the virtual machine is defined by software (the Mach kernel interface), rather than by hardware."
The BSD stuff was kind of bolted on. Very uneasy marriage there.
At one point DEC had a 2 Mach task system that could run VMS processes, but I'm pretty sure that was Mach 3.0 based.
That is to say, Mach 2.0 wasn't as advanced in portability, and the "portability" targeted was different.
After the early days, Solaris did improve, but I think that was because ideas / pieces of BSD (from SunOS) were put back into the OS.
I don't think Solaris pipes / sockets performed better than Mach.
The task/port/thread/pagers are primitives that let Mach run some other OS executables, not made it easy to port Mach to other hardware. There were papers about getting MSDOS and VMS executables to run in Mach tasks. Some startup was making a system to run (pre-OSX) Mac executables.
« microkernels are easier to port » is not a thing.
NeXT did make their own hardware, it was 680x0-based and it was nicer to use than the x86 PC shitboxes it ran on when they stopped making hardware.
« very little assembly » is closest to the truth. NeXTstep and OpenStep were written almost entirely in C and Objective-C and compiled using the GNU toolchain. NeXT was always a hybrid of Unix userspace on top of a Mach microkernel. It’s just not that hard to port a Unixlike OS to another CPU architecture. It’s literally been done since the 1970’s.
However, it is much more difficult to port the OS and maintain binary compatibility with apps created for the previous CPU architecture, which has always been Apple’s special sauce since the original PowerPC Macs.
Obv writing in a portable language and on a portable microkernel helps.
This comment left me shaking my head and facepalming all at once.
At the time, it was.
Per the other thread, I'm not seeing the storyline that the author is arguing that Mac OS will run on ARM but still be first class on Intel architecture. We can assume that is not the case because Apple doesn't half-ass their transitions.
Please highlight what you think the prediction got wrong so we can talk about that specifically.
This is a little drop of good in a ocean of bad.
1. Apple clearly has no problem with 'toxic' (not sure what that means) IP as long as they have access on acceptable terms - which they clearly do with Arm.
2. Apple were almost certainly one of (maybe the only) lead partner for Arm in developing the A64 ISA - they have had a lot more input into A64 than they have into RISC-V.
3. They design their own architecture - they could have built a RISC-V CPU for the Mac if they'd wanted - they don't have to wait for anyone else.
- ARM64 was announced in October 2011. Apple was shipping SoCs based on ARM64 only two years later. Apple can do these things very quickly when it wants to.
- Apple had all the info it would need to base a decision on Arm or RISC-V at the time of the decision to leave Intel. It could have delayed a short while to allow the ecosystem to mature if it had wanted to go for RISC-V.
- It controls a large chunk of the ecosystem anyway (LLVM etc).
I really find the idea that Apple - hardly the most open company in the world (to say the least) - is expected to switch ISAs again to RISC-V for no apparent commercial advantage very, very implausible.
Even in 2022 it may not be wise to start a huge RISC-V project yet for a company like Apple. It’s not mature enough.
I also agree Apple is not an open friendly company. That’s why I think if they do it then it will likely be loaded with proprietary extensions. So it’s not a matter of simply swapping ISAs, it’s completely rethinking the entire stack. That takes time and expertise. The industry isn’t there yet, not at the scale to support what Apple (and others) would like to do.
Edit: rereading it sounds like you think Apple might want their own (version of) ISA which is reasonable except they already had huge input into A64 and are adding their own extensions already anyway.
Anand Shimpi who founded Anandtech has stepped down from Anandtech and is working for few years now at Apple in hardware.
Apple doesn't design chips, they design functionality. Intel design chips that are as much flexible as possible.
Rather, RISC-V's primary advantage over ARM is its openness; vendors can do whatever they want with the ISA without having to pay license fees or maintain compatibility. But this doesn't affect Apple at all; they co-founded ARM, and they have a huge amount of influence over the direction of the architecture along with some sort of special license that allows them to do things other CPU vendors aren't allowed to do (https://news.ycombinator.com/item?id=29782840, https://twitter.com/stuntpants/status/1346470705446092811).
Developing an entirely new high-end CPU mircoarchitecture takes many years and many billions of dollars. It's not something Apple's going to do unless they have a very, very good reason -- and RISC-V being really cool is unfortunately not a good enough reason.
The fact that Arm64 doesn’t have compressed instructions is obviously a very deliberate choice, thus I can’t agree with the notion that RISC-V compressed instructions could be a potential “advantage” over Arm64. Their absence is a massive advantage in many ways that I have explained over and over on HN and it’s the single biggest stupidity in RISC-V for high-end perf (not microcontrollers).
ARMv8 is a nice ISA, and the work that architects do is critical, and it's not easy to develop a precise, clean, extensible, and relatively bug free ISA. But there is relatively little real innovation in it. It's a pretty conventional RISC, warmed over for the modern era. In fact no ISA has any real magic, that's all in the silicon.
There's certainly not hundreds of millions of dollars per year worth. That money is only paid because of the proprietary lock-in and ecosystem around the ISA, which is similar to the proprietary software model, so at some point it would be easy to imagine large chunks of the industry deciding to break away and go to something more open.
It may not inevitably displace ARM entirely, and ARM Ltd might change their ways or open their ISA to prevent it. But it could easily happen too, in the next decade or so.
For that it probably gets access to the full range of Arm IP, including for example the IP associated with big.LITTLE - and there are likely to be others.
There are two areas where RISC-V, for example, does have present a clear advantage for firms: where firms want to innovate on top on an ISA (eg Tenstorrent) or who want to shave cents off their BOM (eg WD).
> I suspect Apple pays very small fees which are not material in the context of the Mac.
Why do you suspect they are very small?
I don't see how that follows. You don't know what their royalty arrangement is. It's probably related to the value of the chip sold. If they sell 20 million macs a year and pay ARM 2 bucks a chip that's 40 million every year. If macs have a gross profit of a couple of billion that's not insignificant. Could be 5% of that. Not to mention several hundred million a year for iphones. Lot of money to pay to be locked into a proprietary ISA when you almost entirely support your own ecosystem, compilers, OSes, etc anyway.
Oh and they are clearly not locked in as they have just changed the ISA for Macs anyway.
That's a lot.
> for which it probably gets access to all of Arm’s IP (eg big.LITTLE) as well
That isn't how their licensing works. They license IP and charge royalties for cores. Apple would pay extra to license ARM Ltd cores they use.
I don't know if there are any public details about license and royalty structure for Apple, but this is ARM Ltd's core business and it's how they make their money. So, probably.
> And of course, they could create any ISA extension, if they wanted.
I'm not sure about that. I think licensees are bound by certain requirements to implement the architecture faithfully. Now Apple obviously has a huge sway and could lobby ARM to make changes it wants. But it does not necessarily have final control of that either.
> But currently they seem to be heading more into the direction of creating additional compute units (like the neural processors) rather than adding new instructions to the CPUs.
Apple designs already deviate from ARM64 specifications, like adding custom instructions: https://github.com/AsahiLinux/docs/wiki/HW:Apple-Instruction...
Apple has invested billions to make a full transition to ARM.
I'd think that they would have to spend at least $50 billion or more to redesign all the Apple Silicon from the iPhone to the Mac Pro, rewrite 5 or 6 operating systems, and beg developers to recompile their apps.
It'd be a nightmare.
I think Apple will stay on ARM for at least 20 years...
I speculate this is somewhat less likely now that the NVidia / ARM deal has fallen through but surely Apple wants the option at least.
Apple probably already use RISC-V designs somewhere in their hardware stack. But the ISA will remain ARM for a long long time.
Even Apple Silicon has a ton of stock ARM cores to control various SoC tasks.
5 years from now it will all be RISC-V and high level bytecode. Arm's ISA victory is Pyrrhic.
Not having to pay royalties for the CPU architecture and the architecture being quite extensible has a lot of charm. That is why completely new CPU designs these days start on RISC-V, especially in research. On the other side, there are plenty of ARM-IPs, so unless you are designing your own processor cores, it often is way more efficient for the project just to include the ARM-IP.
I can see RISC-V might make quite an impact on embedded systems short term, but smartphone vendors basically buy what Qualcomm produces. Until they produce an equally powerful RISC-V based design for less money, they will of course stick with the current architecture.
It is far easier for them to adjust their existing silicon designs than to adopt an entirely new ISA, given equal gains.
What we're going to see now is 20 years of solid innovation on Arm CPUs from Apple. I don't even like Apple at all, and that is apparent to me.