RISC-V Is Inevitable: State of the Union Keynote Argues

ColdStream

It was a decent little talk this one. Now that we are seeing RVA23 chips available we are starting to at least see a lot of software packages actively compiled for the platform. They aren't optimized much at all but they do run. I am cautiously optimistic about the future of RISC-V. It is likely to start biting at the heals of ARM in another 5 years or so, and having no licensing fees makes it very attractive in that sense. Qualcomm and Apple will be very interesting in avoiding as many ARM licensing fees as possible even if initially in embedded systems. But it also allows for a lot of hardware to be locked down just like ARM and so it might not be so great for the end users. Time will tell. All I know is that I look for the seeing Apple Silicon 2 launching in 2036 using this stuff. ;)

cold_pizz4

While the consumer market is still years away from widespread RISC-V adoption, if you pay attention to the embedded / MCU market (especially Espressif & co) you will indeed come to the conclusion that RISC-V is inevitable and software maturity will probably come from these early adopters. Go!

modulovalue

I'm working on making SIMD better in Dart. Dart supports RISC-V as a target architecture for compilation, but I'm not really excited about figuring out how to map the wasm-SIMD-style primitives to RISC-V's RVV and so I don't really plan to look into it at all. This is mostly because their approach to SIMD is so different, but also because I can't test it at all. Are there any RISC-V "machines"? that one can use to do something useful or fun with that someone here could recommend? I guess it would be fun seeing all my SIMD-fiable use-cases become orders of magnitude faster on RISC-V, too, but I sadly never hear anything about machines that use RISC-V.

jhvkjhk

> “CHERI is not an extension; CHERI is a new base,” Asanović clarified to the keynote audience. > Addressing concerns that creating a new base ISA might fracture the open-source community, Asanović offered a devoted defense to EE Times. “CHERI is too invasive to be a simple extension on regular RISC-V, and so needs a new base ISA for that reason,” To me it sounds like they're creating RISC-VI before RISC-V even winning the market.

thrownawaysz

If we go by Apple's architecture history we will get a new one, maybe RISC-V, in 2036. m68k (1984) > PPC (1994) - 10 years PPC (1994) > x86 (2006) - 12 years x86 (2006) > ARM64 (2020) - 14 years ARM64 (2020) > ??? (2036) - 16 years

red_admiral

My money is still on ARM. They, and their clients who produce the actual processors, have options to fight back if RISC-V ever becomes a serious competitor for, say, smartphones.

ltbarcly3

Why can't anyone build a performant RISC-V cpu? The SpacemiT K3 seems to be the fastest available right now, and it's basically a joke. https://www.phoronix.com/review/spacemit-k3-pico-itx/3 I'm starting to get the feeling that there is something fundamentally broken in the RISC-V specification that fundamentally limits performance.

PaulRobinson

Headline could read: "RISC-V adoption is 'inevitable' according to RISC-V advocate at RISC-V conference to people who are invested in RISC-V who had come to hear about state of RISC-V adoption". I'm curious where the data is to support the argument. I am struggling to see the adoption appetite outside of niche applications where licensing costs of existing architectures are a key barrier.

usui

RISC architecture is gonna change everything

sylware

Everything pushing forward RISC-V is a good thing (this time I get it right...) I code RISC-V assembly almost everyday, beyond the major point that it is a NON-IP-LOCKED ISA (unlike arm and x86-64), it feels like it does 'sweet spot' nearly all the time. Namely, I am more into binary specifications which means, if RISC-V is zapped one day, we still have some RISC-V byte code and port to an IP-LOCKED ISA is reasonable. The hard part: _really performant_ micro-architectures for server/desktop/embedded/mobile on latest silicon process. The harder part: getting much binary-only 'critical' software running there (for instance desktop video games). And the super hard part: big mistakes _will be made_, and it is going to hurt ooofely.