Apple to move to RISC-V from Arm for supporting cores | Hacker News Reader

Apple to move to RISC-V from Arm for supporting cores

semianalysis.substack.com

15 pointsCharlesW13 comments

I wonder what their motivation is, perhaps their arm architecture license terms make it worth it for reducing royalties

Mainly because they can. They already have excellent team & experience in designing low power cores from the ground up, and also they have their great LLVM team for the compiler. Core plus compiler, that's all you need for a in-house processor. There are very few companies with this kind of combinations, and those who have them all chose to build their own hardware stack.

When you have the hammer, it becomes a crime to not hit the nail. Especially so when you find out you have a better hammer than your hammer contractor.

I’m interested in what hardware experts think about this too. TFA suggests an opportunity for deeper/proprietary silicon designs, which might be a nice way to create a moat before WinArm PCs and laptops arrive.

“SiFive can offer something Arm cannot, flexibility. Customers can modify their cores by adding hardware accelerators directly into the vector register file. This can be used for extending the X280 core to applications such as DSP, image signal processing, and AI.”

I guess with ARM they can either design their own cores, or buy arm's, but not other arm architecture licence holders. With riscv they can do their own design or choose from a larger list of competing vendors

Makes me wonder if ARM licenses will soon mandate that all processors in an SoC be ARM. There’s a certain hint of ARM desperation in their treatment of Qualcomm over Nuvia IP.

That would only result in no processors in a SoC being ARM.

At most, they'd get some licensees to comply for a single generation of chips. The next one would have given them enough time to rid of ARM.

For most licensees, it wouldn't even be possible to release one generation like that, as most are licensing IP blocks from multiple vendors, which might internally use whatever ISAs. Obviously, the owners of these IP blocks would hurry up and move to RISC-V, too, in order to protect their business models.

I don't understand this, aren't the AMX instructions[1] an example of an Apple-proprietary ARM instruction set extension?

[1]: https://news.ycombinator.com/item?id=32722510

Take a look at e.g. SiFive's core IP offerings.

Given any ARM core (save the wildly inefficient, but faster top performance cores like the X1/X2), SiFive's got one that's like below a third of the size, uses dramatically less power and runs somewhat faster.

This is enabled by the quality of RISC-V's architecture.

The base spec has less than 50 instructions. Even with everything and the kitchensink in there (which is possible; as of the batch of extensions approved in late 2021, RISC-V is not lacking any major features ARMv9 or AMD64 have), RISC-V is still a few hundred instructions, rather than thousands.

And, despite having highly competitive 32bit code density (might be the best by year end, considering with current state of non-finished Zc/B extensions it already is) and the highest code density of 64bit architectures (by comfortable margin), RISC-V is very easy to decode. The compressed code extension does barely even complicate decode, and is still either 2x 16bit instructions or a 32bit one.

In practice, this means cores can be tiny relative to equivalent ARM cores, and SiFive's portfolio is a good demonstration of that.

By contrast:

- AMD64 aka x86 has 1-16 byte instruction length which means a 2-decode or wider implementation has to bruteforce every possible instruction start and discard the bad results. This makes complexity scale exponentially with decode width, and Intel and AMD have found that 4-decode is a practical limit.

- ARMv9's aarch64 is fixed 32bit (yet only slightly easier to decode because of that, relative to thumb2 and RISC-V). This enabled Apple to go 8-decode with the M1. But this comes at the expense of code density: If you want to implement a high performance core, you're going to need a huge L1, which besides huge area and power penalty, is also going to cap the clock the cache can achieve. Regardless, the situation is much better than AMD64(x86), and has enabled Apple to go 8-decode on the M1.

And this is why I think Apple moving to RISC-V in supporting cores is only the first step, and the main cores will eventually follow.

Their motivation is easy: efficiency

They are not attached to a HW, they'll sell you apple and its services, what ever helps them, they'll adopt it

PPC, Intel, ARM, RISC, it doesn't matter

And if they want a smart watch that last more than a mere day, they'll need to get rid of ARM asap anyways

>And if they want a smart watch that last more than a mere day, they'll need to get rid of ARM asap anyways

Unless you have some concrete evidence, I dont think you know what you are talking about.

Yes you are right, i don't know what i am talking about, i'm clueless, that's why apple watch doesn't last more than a mere day, it's because of me

The Apple Watch dont last more than a day has nothing to do with ARM the ISA.

I expect a lot more on HN if you want to suggest something controversial.

Now is your opportunity to change that and educate me

What do you think is their motive? is it because interesting features such as the always-on module? doesn't that improve power efficiency of the device?

Do you think they are scared about the future of ARM? its stagnation, in case of a potential purchase by Microsoft or worse, Qualcomm (king of inefficiency)?

Or because it offers flexibility and modularity that can't be found on ARM?

Reply on news.ycombinator.com