Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Wokis

macrumors 6502a
Jul 3, 2012
931
1,276
I believe Engadget's Upscaled series did a good take on this topic a couple years ago expecting exactly this, co-processors switching from ARM to RISC-V. Less licensing fees for all those little processors that accompany everything.

The main processors moving to RISC-V seems less likely short-term though. I understand it as that it's simply not competitive enough for bleeding edge performance.

 

leman

macrumors Core
Oct 14, 2008
19,517
19,664
I don’t see anything interesting here. Apple uses a bunch of coprocessors to do different things, not all of them ARM to begin with. RISC-V is great for either auxiliary controllers or specialized coprocessors, where you can make the cores compact and extend the base ISA as you need. It might even make sense for the GPU.

But the user-visible ISA will remain ARM for the foreseeable future.

What is the main issue for not being competitive? Compilers?

Besides some areas lacking maturity (e.g. SIMD) my personal opinion that RISC-V simply doesn’t bring anything new of value to personal computing. The performance of modern systems is achieved through micro-architectural implementation details. I see no reason why it would be impossible to build a RISC-V CPU with similar performance to current ARM or x86, I just also don’t see any reason why anyone would attempt it. A small company where RISC-V is attractive due to lower costs probably cannot design a fast CPU.

If RISC-V would at least offer some features that make it fundamentally better for personal computing, that would be an incentive at least. But it does not. The main value of RISC-V is a) that it’s open source and b) that it’s easily extensible and customizable. High performance personal computing doesn’t care about the first part, and it’s actively harmed by the second one. Imagine the mess in software development if different CPUs had principally different features.
 

Xiao_Xi

macrumors 68000
Oct 27, 2021
1,627
1,101
I don’t see anything interesting here.
Although the SemiAnalysis report explains how more companies (e.g. Google) are starting to use SiFive X280, TechPowerUp decided to write about Apple because SemiAnalysis wrote:
SemiAnalysis can confirm that these cores are actively being converted to RISC-V in future generations of hardware.

If RISC-V would at least offer some features that make it fundamentally better for personal computing, that would be an incentive at least. But it does not. The main value of RISC-V is a) that it’s open source and b) that it’s easily extensible and customizable. High performance personal computing doesn’t care about the first part, and it’s actively harmed by the second one. Imagine the mess in software development if different CPUs had principally different features.
If things don't change soon, I see a near future where China uses RISC-V based computers and Western countries use ARM.
 
  • Like
Reactions: psychicist

mr_roboto

macrumors 6502a
Sep 30, 2020
856
1,866
Well Apple used ARM SoCs in Intel Macs for a while so it wouldn't surprise me if they started using Risc-V now they are off Intel.
They're now just 2 years into using Arm as the primary ISA in Macs. They have a very large amount invested in Arm. AArch64 is fundamentally a better ISA than RISC-V. Apple engineers appear to have helped write the AArch64 specifications. Apple has been on the cutting edge of developing Arm features like PAC (pointer authentication) for some time.

So literally the only thing attractive about RISC-V to Apple is the absence of licensing fees, fees which are being paid to a fairly close partner. Balanced against "recovering" those fees are the costs of switching everything to a new ISA not long after they made the transition to Arm - for all that Apple's made it look smooth and easy, they spent a lot behind the scenes accomplishing that, and they'd have to do it again for RISC-V.

So, IMO, there's no rational reason to believe Apple is adopting RISC-V as a user-visible ISA in the near or even medium future. The only place there's scope for it is embedded microcontrollers which run only Apple-provided firmware (meaning nobody outside Apple has to deal with the transition). While that's possible, I personally believe it's unlikely to happen much. Arm doesn't charge much per core, especially for microcontrollers, and keeping the ISA uniform across all the µCs in a SoC is valuable even when you don't expect code sharing between µCs and the application processors. (Same memory consistency model, same data formats, etc.)
 

ADGrant

macrumors 68000
Mar 26, 2018
1,689
1,059
They're now just 2 years into using Arm as the primary ISA in Macs. They have a very large amount invested in Arm. AArch64 is fundamentally a better ISA than RISC-V. Apple engineers appear to have helped write the AArch64 specifications. Apple has been on the cutting edge of developing Arm features like PAC (pointer authentication) for some time.

So literally the only thing attractive about RISC-V to Apple is the absence of licensing fees, fees which are being paid to a fairly close partner. Balanced against "recovering" those fees are the costs of switching everything to a new ISA not long after they made the transition to Arm - for all that Apple's made it look smooth and easy, they spent a lot behind the scenes accomplishing that, and they'd have to do it again for RISC-V.

So, IMO, there's no rational reason to believe Apple is adopting RISC-V as a user-visible ISA in the near or even medium future. The only place there's scope for it is embedded microcontrollers which run only Apple-provided firmware (meaning nobody outside Apple has to deal with the transition). While that's possible, I personally believe it's unlikely to happen much. Arm doesn't charge much per core, especially for microcontrollers, and keeping the ISA uniform across all the µCs in a SoC is valuable even when you don't expect code sharing between µCs and the application processors. (Same memory consistency model, same data formats, etc.)

I have no idea what the terms of the Apple ARM license or how long they intend to support the Intel platform. It seems unlikely that they aren't at least looking at RISC-V. It may not be ready for prime time right now but Apple plays a long game. The transition to Apple Silicon started over a decade ago with the A7.
 

leman

macrumors Core
Oct 14, 2008
19,517
19,664
While that's possible, I personally believe it's unlikely to happen much. Arm doesn't charge much per core, especially for microcontrollers, and keeping the ISA uniform across all the µCs in a SoC is valuable even when you don't expect code sharing between µCs and the application processors. (Same memory consistency model, same data formats, etc.)

ARM64 is still a fairly complex ISA though, and I can imagine that for some domains at least a much reduced RISC-V core will use a smaller area. Another advantage is plenty of opcode space for custom functionality. Memory consistency and data formats are not a problem, that can be made compatible.
 

Xiao_Xi

macrumors 68000
Oct 27, 2021
1,627
1,101
Why do you think RISC-V is not worse? ;)
Honestly, I don't know which one is better because I haven't read anything that explains which one is better.

There is a good list with potential criticisms of RISC-V written by an expert: https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d9982f7618ef68 I agree with most of these.
I'll read it more closely later, but at a quick glance that post only shows that RISC-V is not perfect, not that it is worse than ARM because it doesn't compare RISC-V to ARM.
 

leman

macrumors Core
Oct 14, 2008
19,517
19,664
Honestly, I don't know which one is better because I haven't read anything that explains which one is better.


I'll read it more closely later, but at a quick glance that post only shows that RISC-V is not perfect, not that it is worse than ARM because it doesn't compare RISC-V to ARM.

“Worse” or “better“ is a weird way to talk about these things because it all depends on ”where”. It’s not a judgement that can be made generally. As I wrote above, RISC-V excels where you either need ultracompact simple cores, or if you need custom functionality. General purpose high performance computing however is not one of those things.
 
  • Like
Reactions: koyoot and Gerdi

Gerdi

macrumors 6502
Apr 25, 2020
449
301
I'll read it more closely later, but at a quick glance that post only shows that RISC-V is not perfect, not that it is worse than ARM because it doesn't compare RISC-V to ARM.

Even if it is not explicitly mentioned in all cases, all the issues listed there are absent in aarch64.

In the end it does not really matter much, because in the embedded space, where RISC-V is used, price and customization is more important than having a good ISA for general purpose computing.
 

AppliedMicro

macrumors 68030
Aug 17, 2008
2,830
3,723
As I wrote above, RISC-V excels where you either need ultracompact simple cores, or if you need custom functionality. General purpose high performance computing however is not one of those things.
But isn’t custom functionality exactly what Apple want and what they’ve been developing and putting into their chips?

While many other hardware and SoC manufacturers keep throwing more and more „general purpose“ cores and RAM into their design, Apple seems to invest in and empasise high-performance specialised engines (neural engine, media engine - following encryption engines, that were a thing even in desktop computers before Apple got serious about their oen designs) quite a lot.

Mobile computing designs have become less and less about „high performance general purpose“ computing - but more about specialised engines optimised to provide specialised, custom functionality with high power efficiency.

 

mr_roboto

macrumors 6502a
Sep 30, 2020
856
1,866
But isn’t custom functionality exactly what Apple want and what they’ve been developing and putting into their chips?

While many other hardware and SoC manufacturers keep throwing more and more „general purpose“ cores and RAM into their design, Apple seems to invest in and empasise high-performance specialised engines (neural engine, media engine - following encryption engines, that were a thing even in desktop computers before Apple got serious about their oen designs) quite a lot.

Mobile computing designs have become less and less about „high performance general purpose“ computing - but more about specialised engines optimised to provide specialised, custom functionality with high power efficiency.

There is nothing in RISC-V which makes it uniquely able to support a cut-down version of the ISA, or support customizations. If Apple thinks it would be valuable to define a subset of AArch64 tailored for embedded microcontrollers, they almost certainly have enough freedom to do it even without Arm Holdings' input, and in reality they should have enough sway with ARMH to just collaborate with them and make it official.

Which segues into the two elephants in the room: Apple designed and shipped a minimalist Arm v8 microcontroller in A12 and every generation of Apple Silicon since (codenamed "Chinook"), and Apple's main application processors support AMX, a custom Apple Arm ISA extension for doing high performance matrix math.

So Apple doesn't need RISC-V for microcontrollers or customizability - they've already got both. What would be their motivation for adopting RISC-V in any significant way? To me, seems like it just boils down to whether they're interested in spending a lot of engineering budget to claw back a tiny amount of royalties from ARMH. Seems unlikely.

(The other scenario I can think of is that maybe they've bought out a company or business unit which has an accelerator block Apple wants to integrate, the existing work is built on RISC-V, and they don't want to delay shipping it by converting that work to Arm.)

That medium article you linked used to be all about how RISC-V was inevitably going to steamroll everything and everyone would be using RISC-V for the full stack real soon now. It's good to see that Mr. Engheim has toned his enthusiasm down a bit, because he was leaping to some very unwarranted conclusions.
 
  • Like
Reactions: Xiao_Xi and altaic

ADGrant

macrumors 68000
Mar 26, 2018
1,689
1,059
For the record the A4 was the first Apple-designed SoC and the A6 featured the first Apple-designed CPU.
As you have already pointed out, the A4 was not a custom Apple design and the A6 was a ARM32 Soc. The A7 was the first ARM64 SoC from Apple and therefore probably the first SoC from Apple that they could have ported MacOS to (having abandoned 32 Intel and PowerPC with the Snow Leopard release).
 
  • Like
Reactions: addamas

mr_roboto

macrumors 6502a
Sep 30, 2020
856
1,866
As you have already pointed out, the A4 was not a custom Apple design and the A6 was a ARM32 Soc. The A7 was the first ARM64 SoC from Apple and therefore probably the first SoC from Apple that they could have ported MacOS to (having abandoned 32 Intel and PowerPC with the Snow Leopard release).
A4 absolutely was a custom Apple design. Before A4, Apple was using Samsung-designed SoCs. Because Samsung designed them, Samsung could (and did) use them in their own Android phones. From A4 onwards, Apple designed their own chips which appeared exclusively in Apple products, and Samsung's role was downgraded to a semiconductor fab partner. (And eventually downgraded to just a flash/DRAM memory supplier once Apple transitioned to TSMC.)

I think you're saying A4 wasn't "custom" based on the fact that A4 used lots of blocks designed by outsiders, such as the ARM Cortex-A8 CPU and PowerVR SGX535 GPU. But even in the 2020s, Apple Silicon continues to use blocks designed by outsiders - think USB and PCIe. Yes, over time, they've brought design in-house for the big important differentiators such as CPUs and GPUs, but the A4 is definitely the starting point of Apple designing Apple Silicon.

Also, Apple absolutely could have ported MacOS to 32-bit Apple Silicon. iOS was nothing more (or less) than a slimmed down version of MacOS X with a rethought UI software stack. Would they have wanted to port the full desktop environment to 32-bit AS? No, for a variety of reasons, but technologically this distinction you're trying to make doesn't hold up to scrutiny.

(p.s. Apple didn't abandon 32-bit Intel until Lion aka 10.7.)
 
  • Like
Reactions: MarkZ7 and Basic75

leman

macrumors Core
Oct 14, 2008
19,517
19,664
But isn’t custom functionality exactly what Apple want and what they’ve been developing and putting into their chips?

While many other hardware and SoC manufacturers keep throwing more and more „general purpose“ cores and RAM into their design, Apple seems to invest in and empasise high-performance specialised engines (neural engine, media engine - following encryption engines, that were a thing even in desktop computers before Apple got serious about their oen designs) quite a lot.

Yes, and that’s where RISC-V coprocessors might be interesting for Apple. But here’s the thing: none of these specialized engines are user-visible or directly programmable. They are hidden behind system frameworks so that Apple can change the implementation details at any time.

But the primary software-hardware interface has to be standardized. That will stay ARM64 for the foreseeablefuture.

Mobile computing designs have become less and less about „high performance general purpose“ computing - but more about specialised engines optimised to provide specialised, custom functionality with high power efficiency.

The second part of your statement is certainly true, but it doesn’t mean that the first part is true as well. Advanced coprocessors are very important because they allow compact computers to excel in domains (ML, HPC, video, graphics, audio processing) where they otherwise couldn’t. But they don’t remove the need for general purpose processors. Modern computers need both, and Apple delivers both. The two years old M1 is still the fastest mobile core for things like compiling software or web browsing.
 
  • Like
Reactions: MarkZ7 and Xiao_Xi

ADGrant

macrumors 68000
Mar 26, 2018
1,689
1,059
A4 absolutely was a custom Apple design. Before A4, Apple was using Samsung-designed SoCs. Because Samsung designed them, Samsung could (and did) use them in their own Android phones. From A4 onwards, Apple designed their own chips which appeared exclusively in Apple products, and Samsung's role was downgraded to a semiconductor fab partner. (And eventually downgraded to just a flash/DRAM memory supplier once Apple transitioned to TSMC.)

I think you're saying A4 wasn't "custom" based on the fact that A4 used lots of blocks designed by outsiders, such as the ARM Cortex-A8 CPU and PowerVR SGX535 GPU. But even in the 2020s, Apple Silicon continues to use blocks designed by outsiders - think USB and PCIe. Yes, over time, they've brought design in-house for the big important differentiators such as CPUs and GPUs, but the A4 is definitely the starting point of Apple designing Apple Silicon.

Also, Apple absolutely could have ported MacOS to 32-bit Apple Silicon. iOS was nothing more (or less) than a slimmed down version of MacOS X with a rethought UI software stack. Would they have wanted to port the full desktop environment to 32-bit AS? No, for a variety of reasons, but technologically this distinction you're trying to make doesn't hold up to scrutiny.

(p.s. Apple didn't abandon 32-bit Intel until Lion aka 10.7.)
Yes I am saying the A4 wasn't really custom because Apple used an off the shelf ARM CPU design but yes it was the starting point for Apple designed Silicon. Of course they could have ported 32bit MacOS to ARM32 (it ran on 32bit CPUss for years) but why would they bother. They aren't Microsoft.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.