Ask HN: Why does Apple use an architectural license from ARM at all?
5 comments
"RISC" is not an ISA. If you meant "RISC-V", that wasn't anywhere near ready in 2020, let alone whenever it was that Apple made their decision to use Arm in the Mac and started working towards it.
You can't license x86 -- and wouldn't want to if you don't have a requirement to run old x86 binaries.
> Apple could have even made their own "Apple Instruction Set" instead
Some people (I'm thinking of a saffer here) claim Aarch64 is the Apple Instruction Set, that Apple did much of the design work on it based on analysis of Mac software, and that Arm really wasn't all that interested in 64 bit without Apple pushing them.
I'm not entirely persuaded by all of that theory, but I don't have the kind of visibility into either Apple or Arm to know.
In particular, I suspect that Arm started work on their 64 bit ISA pretty much as soon as AMD had some success with Opteron and Athlon64 and showed that the 64 bit future was not going to be entirely (or at all) Itanic. A start in 2004 to publication in 2011 is probably about the right amount of time.
You can't license x86 -- and wouldn't want to if you don't have a requirement to run old x86 binaries.
> Apple could have even made their own "Apple Instruction Set" instead
Some people (I'm thinking of a saffer here) claim Aarch64 is the Apple Instruction Set, that Apple did much of the design work on it based on analysis of Mac software, and that Arm really wasn't all that interested in 64 bit without Apple pushing them.
I'm not entirely persuaded by all of that theory, but I don't have the kind of visibility into either Apple or Arm to know.
In particular, I suspect that Arm started work on their 64 bit ISA pretty much as soon as AMD had some success with Opteron and Athlon64 and showed that the 64 bit future was not going to be entirely (or at all) Itanic. A start in 2004 to publication in 2011 is probably about the right amount of time.
I'm still researching my question, and yet other articles say Apple has recently recruited RISC-V experts.
My question isn't a concrete question of why Apple chose ARM (which is speculation), but rather why generically a large computer company like Apple would choose to license an ISA at all when they have the wealth/resources to build one from ground up. Why leave that to another company to dictate the HW/SW interface? Is an ISA that hard to figure out? What are the general pros and cons.
My question isn't a concrete question of why Apple chose ARM (which is speculation), but rather why generically a large computer company like Apple would choose to license an ISA at all when they have the wealth/resources to build one from ground up. Why leave that to another company to dictate the HW/SW interface? Is an ISA that hard to figure out? What are the general pros and cons.
> Apple has recently recruited RISC-V experts
Sure, as have many companies. Almost everyone is replacing the numerous tiny housekeeping CPUs in modern chips with RISC-V.
Samsung said in December 2019 that their upcoming phone (Galaxy S20) has two RISC-V processors: one controlling the camera and the other the 5G radio.
That's quite different to replacing the main user/app-facing application processor cores.
Apple could well already be converting the main processors in products such as the Apple Watch, AirPods, AppleTV to RISC-V. Or not. Those products either aren't user-programmable, or else apps are uploaded to Apple as LLVM bitcode, which Apple can then compile to machine code for any CPU they desire.
> why generically a large computer company like Apple would choose to license an ISA at all
Because while an ISA is relatively easy to design (but many many people have still made awful ones) that is only the easiest part of the process. The biggest job by far is writing or porting all the necessary software, starting with compilers.
And there is simply no benefit in making a new ISA. Historically, the usual reason was that other people owned the ISA and wouldn't license it at all, or it cost too much, or you couldn't make any modifications to it.
Going forward now, with RISC-V existing, all those reasons disappear. It's not massively technically better than the Arm ISAs, but it's not worse either, and the FREEDOM aspect is unbeatable. There is really no reason at all for anyone in future to make their own ISA and software from scratch when they can just start from RISC-V and add their own special features. Not unless they are doing something absolutely radically different to every existing and historical computer.
Sure, as have many companies. Almost everyone is replacing the numerous tiny housekeeping CPUs in modern chips with RISC-V.
Samsung said in December 2019 that their upcoming phone (Galaxy S20) has two RISC-V processors: one controlling the camera and the other the 5G radio.
That's quite different to replacing the main user/app-facing application processor cores.
Apple could well already be converting the main processors in products such as the Apple Watch, AirPods, AppleTV to RISC-V. Or not. Those products either aren't user-programmable, or else apps are uploaded to Apple as LLVM bitcode, which Apple can then compile to machine code for any CPU they desire.
> why generically a large computer company like Apple would choose to license an ISA at all
Because while an ISA is relatively easy to design (but many many people have still made awful ones) that is only the easiest part of the process. The biggest job by far is writing or porting all the necessary software, starting with compilers.
And there is simply no benefit in making a new ISA. Historically, the usual reason was that other people owned the ISA and wouldn't license it at all, or it cost too much, or you couldn't make any modifications to it.
Going forward now, with RISC-V existing, all those reasons disappear. It's not massively technically better than the Arm ISAs, but it's not worse either, and the FREEDOM aspect is unbeatable. There is really no reason at all for anyone in future to make their own ISA and software from scratch when they can just start from RISC-V and add their own special features. Not unless they are doing something absolutely radically different to every existing and historical computer.
No, the articles specifically say that one reason Apple recruits RISC-V experts is as an alternate backup plan, going well beyond secondary processors.
I don't think that even ISAs today are easy to design. They look easy because the primary deliverable is thousands of boring pages of specification (obviously plus simulators and reference designs and probably other things). The actual issues today are things like concurrency and memory consistency model, which an ISA would require parallelism hardware experts to design it correctly and effectively. And the possible interactions of ISAs at the level of SoCs design, this is basically an open problem. And there are already many nuances about ISAs today which affect microarchitecture, power, ISA extensions like signal/neural processing, etc., and these matter even to consumer markets (in contrast to high performance / industrial computing) because a computer company ultimately wants to be cost efficient going about this.
I did some more reading last night. It turns out the biggest reason given is that ISA is a duopoly between x86 and ARM: that is, this is patent minefield. Anyone who tries to make a new ISA has to avoid patent troll traps, this was from a scholar.google paper. It's a good economic point, that by creating a high barrier to entry, the duopoly has inhibited ISA development for many years. The RISC-V being a way out of that, is one promising answer.
Also I found that Apple pays much less royalties to ARM with its special license compared to other companies (including but not only Qualcomm) that license ARM. The architectural license is supposed to cost especially more, but Apple gets a special discount for historical reasons, like 30 ¢ per chip.
A couple articles also point out that Apple with its RISC-V R&D can use it as leverage when renegotiating - "If ARM doesn't give us a good license deal, we'll just switch to RISC-V!".
A related point is that there's a lot of infrastructure around ISA - testing/validation flows, compiling, etc., and ARM has a huge ecosystem of this. Here I guess Apple could do this, they could grow their own, which becomes a matter of time and cost. So it's more a practical reason to go with an existing ISA and then extend it, or modify the microarchitectural implementation or even redesign it completely.
From a scientific standpoint, there will probably always be a need for new ISAs. For every new HW/SW concurrency model or new paradigm (deep nets looming on the horizon), there will be revisions to the HW/SW interface. Note also that the Spectre authors wrote that proper the way to avoid such exploits is to fundamentally change instruction set architectures. About 15 years ago I met people (professors) who thought computers were basically done, today I'm not so sure any more.
P.S. RISC-V itself is a ground-up creation after its designers looked carefully at OpenRISC and decided not to build on it, for technical reasons. History will probably repeat itself.
I don't think that even ISAs today are easy to design. They look easy because the primary deliverable is thousands of boring pages of specification (obviously plus simulators and reference designs and probably other things). The actual issues today are things like concurrency and memory consistency model, which an ISA would require parallelism hardware experts to design it correctly and effectively. And the possible interactions of ISAs at the level of SoCs design, this is basically an open problem. And there are already many nuances about ISAs today which affect microarchitecture, power, ISA extensions like signal/neural processing, etc., and these matter even to consumer markets (in contrast to high performance / industrial computing) because a computer company ultimately wants to be cost efficient going about this.
I did some more reading last night. It turns out the biggest reason given is that ISA is a duopoly between x86 and ARM: that is, this is patent minefield. Anyone who tries to make a new ISA has to avoid patent troll traps, this was from a scholar.google paper. It's a good economic point, that by creating a high barrier to entry, the duopoly has inhibited ISA development for many years. The RISC-V being a way out of that, is one promising answer.
Also I found that Apple pays much less royalties to ARM with its special license compared to other companies (including but not only Qualcomm) that license ARM. The architectural license is supposed to cost especially more, but Apple gets a special discount for historical reasons, like 30 ¢ per chip.
A couple articles also point out that Apple with its RISC-V R&D can use it as leverage when renegotiating - "If ARM doesn't give us a good license deal, we'll just switch to RISC-V!".
A related point is that there's a lot of infrastructure around ISA - testing/validation flows, compiling, etc., and ARM has a huge ecosystem of this. Here I guess Apple could do this, they could grow their own, which becomes a matter of time and cost. So it's more a practical reason to go with an existing ISA and then extend it, or modify the microarchitectural implementation or even redesign it completely.
From a scientific standpoint, there will probably always be a need for new ISAs. For every new HW/SW concurrency model or new paradigm (deep nets looming on the horizon), there will be revisions to the HW/SW interface. Note also that the Spectre authors wrote that proper the way to avoid such exploits is to fundamentally change instruction set architectures. About 15 years ago I met people (professors) who thought computers were basically done, today I'm not so sure any more.
P.S. RISC-V itself is a ground-up creation after its designers looked carefully at OpenRISC and decided not to build on it, for technical reasons. History will probably repeat itself.
Mate. You reference some random unspecified articles on the internet. The internet has thigs of widely varying quality and accuracy. If they are claiming to know e.g. what Apple's contract terms are with Arm then they almost certainly don't have any actual information.
> I did some more reading last night.
Great nice. I'm glad you're researching RISC-V. Welcome aboard.
I've been heavily involved in RISC-V since late 2016 when I bought my first board. In 2017 I co-authored a conference paper on a high performance emulator for RISC-V on x86_64. In early 2018 I started working for RISC-V pioneers SiFive -- my H-1B visa paperwork says they have 32 employees. It was under 20 the first time in was in their office for a quiet chat (which turned out to be the job interview). You'll find my name in the acknowledgements in the RISC-V User-level ISA Manual, and also the specs for the Bitmanip and Vector extensions. I was heavily involved for example in writing the example RVV code in the manual, adding support for the needed V instructions to the Spike emulator, being on the working group designing the V instructions, and modifying both example code and emulator to track changes in the ISA design, which were quite radical pre draft 0.7. I was also around when that memory consistency model was being developed, though not directly involved. RISC-V got world-class experts in academia and industry to design that. Other ISAs probably just get a few company employees to bang something out, and try to fix it up later when academic research points out problems.
> I did some more reading last night.
Great nice. I'm glad you're researching RISC-V. Welcome aboard.
I've been heavily involved in RISC-V since late 2016 when I bought my first board. In 2017 I co-authored a conference paper on a high performance emulator for RISC-V on x86_64. In early 2018 I started working for RISC-V pioneers SiFive -- my H-1B visa paperwork says they have 32 employees. It was under 20 the first time in was in their office for a quiet chat (which turned out to be the job interview). You'll find my name in the acknowledgements in the RISC-V User-level ISA Manual, and also the specs for the Bitmanip and Vector extensions. I was heavily involved for example in writing the example RVV code in the manual, adding support for the needed V instructions to the Spike emulator, being on the working group designing the V instructions, and modifying both example code and emulator to track changes in the ISA design, which were quite radical pre draft 0.7. I was also around when that memory consistency model was being developed, though not directly involved. RISC-V got world-class experts in academia and industry to design that. Other ISAs probably just get a few company employees to bang something out, and try to fix it up later when academic research points out problems.
Apple has a long history with ARM, going back to the Newton. Back then (or even in the early iPhone era) they didn't have the time or resources to develop their own implementation. They could afford to develop their own ISA now, but why would they? The modern ARM ISA is great. It's hard to picture beating it significantly. And it would introduce another incompatibility, requiring another era of fat binaries.
Apple's ARM license may be an artifact of the shared history of the two companies.
https://en.m.wikipedia.org/wiki/Arm_Holdings#Founding
Development of the Newton handheld PDA led Apple to seek a capable, efficient, embedded processor architecture. They worked with Acorn and VLSI Technologies to build upon Acorn's RISC design.
(Apple initially used the "Hobbit" embedded microcontroller from AT&T, but Newton's ambitious design required three of them, plus support chips. Development costs escalated, Apple sought an alternative, and helped develop ARM into a licensed, flexible reality.)
https://en.m.wikipedia.org/wiki/Arm_Holdings#Founding
Development of the Newton handheld PDA led Apple to seek a capable, efficient, embedded processor architecture. They worked with Acorn and VLSI Technologies to build upon Acorn's RISC design.
(Apple initially used the "Hobbit" embedded microcontroller from AT&T, but Newton's ambitious design required three of them, plus support chips. Development costs escalated, Apple sought an alternative, and helped develop ARM into a licensed, flexible reality.)
Apple already had a license for its mobile devices, and using the same ISA for the desktop machines reduced duplicate development across the platforms.
"many articles claim Apple is nontrivially re-implementing the design"
citation needed.
citation needed.
Who needs a citation? Apple shipped 64 bit Arm machines (iPhone 5s) in 2013, 18 months before Arm's own 64 bit cores were ready.
Many articles explain why other companies buy ARM IP in order to use reference ARM CPU designs as-is, or to make incremental modifications or extensions to those; and yet many articles claim Apple is nontrivially re-implementing the design to achieve the performances and power efficiencies of the M series chips.
Other articles also explain the advantages of compatibility with a preexisting ecosystem of ARM-compatible devices; but, that does not strike me as a primary compelling reason why a major company would care, other than many of Apple's own mobile devices were already ARM architectures? Let's say it makes sense for a laptop and a phone to share a unified processor architecture so they can run the same code--then Apple could have even made their own "Apple Instruction Set" instead?
Is there some kind of technical advantage to the ARM architecture over say, licensing the RISC or the (supposedly aging) x86 architectures? Or is it that there are more ARM architecture engineers out there? Are Instruction Set Architectures so difficult to design, that a special company needs to own and maintain the IP for it?
After reading a bunch of articles I did not feel I actually understood this at all. Many kind of touched on it circumstantially, but I felt they did not directly explain the advantage or rationale for doing so the way Apple did (I thought of the PowerPC but I assume in that case, Apple/IBM/Motorola worked together to specify an architecture). I'd appreciate any insight or pointers to actually good articles on this.