RISC-V getting closer to come to Apple silicon?

[AppliedMicro]

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

I‘m not sure if they want to „give it back“ to the wider ARM platform - when they can keep it proprietary as a competitive advantage.

That will stay ARM64 for the foreseeablefuture.

Oh, I have little doubt about that, for at least a decade. After all, they just migrated their Macs to ARM64, and I don’t think they’re going to give up a unified instruction set and platform architecture across their device range easily.

Unless… they do see a great advantage of migrating to something else (RISC-V) instead of ARM - though at this point it’s not clear what and where that advantage could be. Even less so, when considering how much ARM has been optimised throughout the whole „supply chain“ of design, manufacturing and software optimisation, due to being the dominant architecture in mobile, handheld computing for more than a decade. And again, much of the „heavy lifting“ is done by specialised cores/parts/„engines“ anyway.

Of course they could have ported 32bit MacOS to ARM32 (it ran on 32bit CPUss for years) but why would they bother

Well, they did port OS X to IA-32, even though (non-64 bit) Macs lasted for barely two years. But of course they had a much more pressing need to upgrade from the stagnating G4 at this point. In hindsight, the speculations of Apple acquiring PA Semi to „build a mobile G5“ makes me smile, when you consider how far we’ve come since then.

 

[altaic]

Even less so, when considering how much ARM has been optimised throughout the whole „supply chain“ of design, manufacturing and software optimisation, due to being the dominant architecture in mobile, handheld computing for more than a decade.

Your other points are interesting, but this one has no basis these days.

 

[leman]

Your other points are interesting, but this one has no basis these days.

Why not? Compiler backends targeting ARM64 are much more mature than RISC-V, same can be said about developer knowledge.

 

[altaic]

Why not? Compiler backends targeting ARM64 are much more mature than RISC-V, same can be said about developer knowledge.

Compiler optimization pipelines and language theory are much better than developers these days, regardless of the target. A small effort toward rigorous implementation pays off.

 

[leman]

Compiler optimization pipelines and language theory are much better than developers these days, regardless of the target. A small effort toward rigorous implementation pays off.

Sure, for 99% of the code, but what about that other 1%? Like, how many RISC-V implementations are there for popular low-level libraries where intimate knowledge of the architecture is required to achieve good (or even correct) performance?

 

[Gerdi]

Compiler optimization pipelines and language theory are much better than developers these days, regardless of the target. A small effort toward rigorous implementation pays off.

You pretend, that everything is native C/C++ these days, which is far from the truth. Major frameworks, like Mono are largely incomplete for RISC-V and this includes all SW, which are based on these frameworks. For example the Unity game engine relies on .Net (e.g. Mono or .Net core).
Second, even if we are restricting our view to C/C++, major libraries, which require intrinsics, are not available for RISC-V. Example Intel Embree library only has AVX/SSE or NEON backends (where NEON is just a wrapper for AVX/SSE). All major rendering packages rely on Embree.

In addition, there is no big push to getting the SW in place for RISC-V, as there are no consumer products, which are using RISC-V as consumer facing architecture at all. In the embedded architecture space, no one cares about such frameworks/libraries.

 

[Xiao_Xi]

In addition, there is no big push to getting the SW in place for RISC-V, as there are no consumer products, which are using RISC-V as consumer facing architecture at all. In the embedded architecture space, no one cares about such frameworks/libraries.

RISC-V SoCs are following in the footsteps of ARM SoCs: first IoT, then server and finally desktop. Software maturity is a matter of time. ARM's ISA has shown that lack of software does not prevent an ISA from becoming popular, but the inherent flaws in the ISA could.

 

[leman]

RISC-V SoCs are following in the footsteps of ARM SoCs: first IoT, then server and finally desktop. Software maturity is a matter of time. ARM's ISA has shown that lack of software does not prevent an ISA from becoming popular, but the inherent flaws in the ISA could.

The only currently shipping successful RISC-V products are highly specialized accelerators. I am not aware of much presence in the IoT or server market.

Can RISC-V one day dominate the scene? Sure, why not! I just don’t understand why some folks are suggesting that its dominance is a done deal. Still a lot of hurdles to clear…

 

[ADGrant]

Well, they did port OS X to IA-32, even though (non-64 bit) Macs lasted for barely two years. But of course they had a much more pressing need to upgrade from the stagnating G4 at this point.

I am not sure about that. I think OS-X was always running on IA-32. It was based on the NeXTSTEP operating system which was ported to the 486 in the early 90s.

 

[Xiao_Xi]

The only currently shipping successful RISC-V products are highly specialized accelerators. I am not aware of much presence in the IoT or server market.

Probably the most popular RISC-V based SoC for IoT is the ESP32-C3.

ESP32-C3 Wi-Fi & BLE 5 SoC | Espressif Systems

ESP32-C3 is a cost-effective RISC-V SoC with Wi-Fi 4 and Bluetooth 5 (LE) connectivity for secure IoT applications.

www.espressif.com

 

[Gerdi]

RISC-V SoCs are following in the footsteps of ARM SoCs: first IoT, then server and finally desktop.

Why do you believe this is set in stone? It could as well stay in the embedded world forever - where it provides meaningful advantages.

 

[AppliedMicro]

I think OS-X was always running on IA-32. It was based on the NeXTSTEP operating system

I think it‘s safe to assume that their porting efforts didn’t start from scratch for 10.4. They probably had builds running in labs to some degree of completeness during all these years. Shipping an OS as a feature-complete consumer product, and including a PowerPC translation layer is still something else though.

What I meant is this: they shipped a complete 32-bit OS X, while selling 32-bit Intel Mac devices for less than two years - when they could also have waited for 64-bit Intel notebook CPUs to do and moved straight to x64.

Why do you believe this is set in stone?

The poster‘s user name may give a hint, and he/she said it earlier:
Choice of architecture may become a more „political“ than technological question.

Is it set in stone? Certainly doesn’t look that way. But I‘m very sure some countries are considering pouring their efforts into RISC-V for technological self-reliance.

 

[Xiao_Xi]

Why do you believe this is set in stone? It could as well stay in the embedded world forever - where it provides meaningful advantages.

Choice of architecture may become a more „political“ than technological question.

No country or company can stop you from using RISC-V. Thus, Chinese companies are investing heavily in RISC-V.

Even if RISC-V ISA has some design flaws that ARM ISA does not, I have not yet read what the consequences of those flaws are. Will RISC-V based SoCs be slower/more expensive/less efficient than ARM based SoCs?

 

[mr_roboto]

I‘m not sure if they want to „give it back“ to the wider ARM platform - when they can keep it proprietary as a competitive advantage.

Apple didn't have to "give back" the AArch64 ISA itself, but they did. (There's all sorts of info floating out there that Apple basically co-wrote the AArch64 ISA spec, which is why they were the first to ship mass market silicon by quite a bit.)

Despite their rep, Apple doesn't want their platforms on a fully proprietary Apple ISA. That would increase the friction for people porting software to iOS and macOS quite a lot, which would not be good for Apple. @Gerdi has a post on this page giving examples of why merely being a less popular ISA makes life harder. Unless you manage to take over everything, fully proprietary ISA locks you into being less popular, and that's bad.

(Note that Apple's custom AMX extension is no exception to this rule. Apple's getting away with it only because it is not public-facing and matrix math coprocessor extensions aren't yet widespread enough to cause porting friction. They used reserved opcodes, barely acknowledge its existence, do not ship compilers or other software tooling to the public, and hid access behind a special mode bit so that ordinary user code just gets illegal instruction errors if it tries to run AMX opcodes. At present, it's something only Apple's system libraries - primarily Accelerate.framework - can sanely use. If they ever want to change course and provide the public with access and dev tools, they will almost certainly push Arm to standardize and publish AMX as an official Arm ISA extension.)

 

[mr_roboto]

RISC-V SoCs are following in the footsteps of ARM SoCs: first IoT, then server and finally desktop. Software maturity is a matter of time. ARM's ISA has shown that lack of software does not prevent an ISA from becoming popular, but the inherent flaws in the ISA could.

Arm did not go from IoT to server to desktop. It started on the desktop in the 1980s, long before some marketing weirdo invented the "IoT" buzzword. After some difficult times in the 1990s, in the 2000s Arm saw wide success in cell phones and tablets. Now it's moving from phones to both desktop and server, with desktop taking the lead.

RISC-V isn't following a great path to end up on the desktop right now. You need high performance implementations, and to get to those you need a large software market which demands high performance, as otherwise there won't be the hardware sales volume to justify spending all that money engineering a high performance core. It's very much a chicken-and-egg problem, which means it's not easy to get the process started.

Arm had the advantage of a one-time opportunity: in the 2000s, Intel foolishly didn't take the young mobile phone market seriously enough early enough, and let Arm become the default choice for Apple and others. (This was mostly because it didn't have high enough profit margins for Intel's tastes.)

The breakout success of Arm-based smartphones lead to a virtuous cycle of performance improvements driving demand for more smartphones driving demand for more performance improvements. That's how we got to the point where phone cores were so close to desktop and server performance levels that it was inevitable someone like Apple would make the obvious move.

I don't see that virtuous cycle happening for RiSC-V yet. The places where RISC-V has had success so far don't seem to care much about performance, and have no obvious future demand for it. IoT junk certainly doesn't. So far the most plausible path there is something like the Chinese government artificially pushing it forwards.

 

[leman]

No country or company can stop you from using RISC-V. Thus, Chinese companies are investing heavily in RISC-V.

Not only RISC-V, China is also actively developing their own ISA (LoongArch)

Even if RISC-V ISA has some design flaws that ARM ISA does not, I have not yet read what the consequences of those flaws are. Will RISC-V based SoCs be slower/more expensive/less efficient than ARM based SoCs?

As for now, the main problem of RISC-V simply lacks functionality (e.g. no standardized flexible SIMD instructions). As to the rest, there is no reason to assume that RISC-V CPUs will be slower or less efficient, just like there is no reason to assume they will be faster or more efficient.

 

[Gerdi]

At present, it's something only Apple's system libraries - primarily Accelerate.framework - can sanely use. If they ever want to change course and provide the public with access and dev tools, they will almost certainly push Arm to standardize and publish AMX as an official Arm ISA extension.)

Thing is, ARMv9 has its own matrix extensions via SVE2s SME (scalable matrix extension). I could imagine that Apple deprecates AMX in favour of SME.
At least I do not see ARM adopting AMX if they already have SME.

 

[mr_roboto]

Thing is, ARMv9 has its own matrix extensions via SVE2s SME (scalable matrix extension). I could imagine that Apple deprecates AMX in favour of SME.
At least I do not see ARM adopting AMX if they already have SME.

Ah, I wasn't aware of SME. Yes, given that it exists, it wouldn't make sense for Arm to adopt AMX.

 

[Xiao_Xi]

It may be more of an expensive toy than a competent computer, but Chinese companies are trying to bring RISC-V SoCs to notebooks.

World's First Laptop with RISC-V Processor Now Available

Alibaba gets the first RISC-V laptop on sale

www.tomshardware.com

Info of the SoC:

平头哥半导体

平头哥半导体有限公司成立于2018年9月19日，是阿里巴巴集团的全资半导体芯片业务主体。平头哥拥有端云一体全栈产品系列，涵盖数据中心人工智能芯片、处理器IP授权等，实现芯片端到端设计链路全覆盖。

www.t-head.cn

 

[ADGrant]

Arm did not go from IoT to server to desktop. It started on the desktop in the 1980s, long before some marketing weirdo invented the "IoT" buzzword. After some difficult times in the 1990s, in the 2000s Arm saw wide success in cell phones and tablets. Now it's moving from phones to both desktop and server, with desktop taking the lead.

I believe the first ARM hardware Acorn ever shipped was a coprocessor for the BBC Model B in 1986:

Acorn ARM Evaluation System - Peripheral - Computing History

The Acorn ARM Evaluation System for the BBC Micro was one of the first production RISC processors.The Acorn ARM Evaluation System for the BBC Micro was one of the first production RISC processors. ...

www.computinghistory.org.uk

 

[Xiao_Xi]

It seems that the first RISC-V SoCs coming to user-facing applications could be next year.

Ventana RISC-V CPUs Beating Next Generation Intel Sapphire Rapids! – Overview of 13 RISC-V Companies, CPUs, and Ecosystem

SiFive, Tenstorrent, Rivos, Codasip, Akeana, Alibaba, Imagination, Western Digital, Andes, Krakatoa, MIPS, XMOS, and Ventana

www.semianalysis.com

 

[camotwen]

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.

The same exact reason it dominates the embedded world: being free makes it easily customisable/extendable. I bet modifying the arm architecture is technically feasible, but much more complicated in practice due to all the legal issues.

In any case, there are many advantages to RISC-V that are not strictly technical: after all the fiasco with NVIDIA trying to purchase ARM, and the fact that CISC-ISAs are dying, there is no way all major companies are gonna leave the monopoly of RISC-ISA processors to ARM (especially considering that ARM has not even demonstrated that it can power desktops efficiently with the exception of Apple silicon ones). And as we are reaching the limits of silicon performance, domain specific computing will be becoming more and more important, so even if RISC-V ends up never touching the main cpu, it does not mean that its roles in computing is inconsequential.

 

[leman]

I just stumbled upon this great post about RISC-V: https://lobste.rs/s/icegvf/will_risc_v_revolutionize_computing#c_8wbb6t

I have always been skeptical about RISC-V in general computing space, but not being a CPU design expert I struggle with expressing my intuitions as words. I think Chisnall‘s post really hits the nail on it’s head. Fragmentation, poor use of the encoding space and premature optimization are key issues with RISC-V, limiting its potential in general-purpose computing space. This is an ISA designed first and foremost for simple in-order architectures.

 

[Xiao_Xi]

I think Chisnall‘s post really hits the nail on it’s head. Fragmentation, poor use of the encoding space and premature optimization are key issues with RISC-V, limiting its potential in general-purpose computing space. This is an ISA designed first and foremost for simple in-order architectures.

I'm not sure about the other points, but the RISC-V organization has recognized the first point and has created profiles to avoid fragmentation. Also, the fence.tso instruction is now mandatory.

This is an ISA designed first and foremost for simple in-order architectures.

What makes you think ARM64 is more suitable for out-of-order SoCs?

The Berkeley Out-of-Order Machine (BOOM): An Industry-Competitive, Synthesizable, Parameterized RISC-V Processor

BOOM is a synthesizable, parameterized, superscalar out-of-order RISC-V core designed to serve as the prototypical baseline processor for future micro-architectural studies of out-of-order processors. Our goal is to provide a readable, open-source implementation for use in education, research...

apps.dtic.mil

It looks like the RISC-V organization will finish the remaining pieces of the standard this year and 2024 will be key to showing the true potential of RISC-V SoCs.

 

[leman]

What makes you think ARM64 is more suitable for out-of-order SoCs?

ARM64 is designed to pack a lot of information into a single instruction. Many ARM64 instructions can be efficiently decoded and scheduled as multiple operations on a modern OOO core. In other words, the goal is to maximize the useful information per instruction.

In contrast, RISC-V seems to be designed to simplify the execution of individual instructions. It looks like an ISA where the primary goal is to enable simple hardware implementations. This is great, but this kind of early optimization means that extracting more performance is going to be difficult. RISC-V authors explicitly mention operation fusion to solve this problem - the CPU will analyze instruction sequences and combine them into a single operation that can be executed more efficiently. But this is not free as it requires power and complex logic. Basically, the idea is that by pursuing extreme simplicity RISC-V might have sabotaged its ability to scale. Time will tell how much this is an issue.

View attachment 2135363

Not sure what is the relevance of this?

It looks like the RISC-V organization will finish the remaining pieces of the standard this year and 2024 will be key to showing the true potential of RISC-V SoCs.

Looking forward to it!