Hacker News Reader

Comment by Vt71fcAqt7 | Hacker News Reader

>That's not going to happen unless Apple decides to switch from ARM to RISC-V, and... why would they? They've got 15 years experience and essentially full control on ARM.

Two points here.

• First off, Apple developers are not binded to Apple. The knkwledge gained can be used elsewhere. See Rivos and Nuvia for example.

• Second, Apple reportedly has already ported many of it's secondary cores to RISC-V. It's not unreasonable that they will switch in 10 years or so.

View on HN

For me, those two points make it clear that it would be possible for Apple to port to RISC-V. But it's still not clear what advantages they would gain from doing so, given that their ARM license appears to let them do whatever they want with CPUs that they design themselves.

The first point precludes Apple's gain from the discussion.

Apple reportedly has already ported many of it's secondary cores to RISC-V

Really? In current hardware or is this speculation?

>Many dismiss RISC-V for its lack of software ecosystem as a significant roadblock for datacenter and client adoption, but RISC-V is quickly becoming the standard everywhere that isn’t exposed to the OS. For example, Apple’s A15 has more than a dozen Arm-based CPU cores distributed across the die for various non-user-facing functions. SemiAnalysis can confirm that these cores are actively being converted to RISC-V in future generations of hardware.[0]

So to answer your question, it is not in currently in hardware, but it is more than just speculation.

[0]https://www.semianalysis.com/p/sifive-powers-google-tpu-nasa...

If you've got some management core somewhere in your silicon you can, with RISC-V, give it a MMU but no FPU and save area. You're going to be writing custom embedded code anyways so you get to save silicon by only incorporating the features that you need instead of having to meet the full ARM spec. And you can add your own custom instructions for the job at hand pretty easily.

That would all be a terrible idea if you were doing it for a core intended to run user applications, but that's not what Apple, Western Digital, NVidia are embracing RISC-V for embedded cores. If I were ARM I'd honestly be much more worried about RISC-V's threat to my R and M series cores than my A series cores.

Arm64 allows FPU-less designs. There are some around…

Sure. The FPU is optional on a Cortex M2, for instance. But those don't have MMUs. You'd certainly need an expensive architectural license to make something with an MMU but no FPU if you wanted to and given all the requirements ARM normally imposes for software compatibility[1] between cores I'd tend to doubt that they'd let you make something like that.

[1] Explicitly testing that you don't implement total store ordering by default is one requirement I've heard people talk about to get a custom core licensed.

Apple has an architecture license (otherwise they could not design their own cores, which they’ve been doing for close to a decade), and already had the ability to take liberties beyond what the average architecture licensee can, owing to being one of ARM’s founders.

There are arm64 designs with MMUs but not FPUs. See Cortex-R82.

That [1] is wrong too. Tegra Xavier shipped with sequential consistency out of the box :)

Don’t think any are shipping, but they’re hiring RISC-V engineers.

> it’s not unreasonable that they will switch in 10 years or so.

You’ve not provided any rationale at all for why they should switch their application cores let alone on this specific timetable.

Switching is an expensive business and there has to be a major business benefit for Apple in return.

Reply on news.ycombinator.com