Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

eetimes.com

Post reply on HN
Print view View original

111–120 of 142 posts

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

#111

Post by tredre3 »

invokestatic wrote: post #88
rzerowan wrote: post #76

Earlier quoted context omitted.

I believe in microcontrollers its already pretty ubiquitous , see their utilisation by WesternDigital with their SwerV core thats already shipping since 2019. At speeds and complexity comparable to desktop/server cores from Intel/AMD they are still lagging in perf though improving as more cores get deployed. Also to add into the mix the whole geopolitics with non-US players hedging. So potential is there will just de…

Firmware & systems dev here, ARM still dominates in the microcontroller space. There are some niche offerings from major vendors but again they are niche. Espressif is the sole exception with their newer ESP32-C series chips, but they can get away with it due to their massive HAL. ARM Cortex is still the standard because there’s a decade or two of inertia behind it. An apt comparison would be C vs Rust. Yes, Rust may…

I'm a fellow embedded dev and I agree, arm is still ubiquitous in all applications I've worked on in the past 10 years. I've used the rp2350 in a commercial application recently and whether or not we'd ignore the risc-v cores wasn't even a question. As a hobbyist however I'm glad that they're there!

Just a nit-pick: risc-v isn't limited to the ESP32-C line. All of their chips are risc-v except the OG/S/S2/S3. A few years ago they've stated that the S3 would be the last xtensa chip and they seem to have held to that, the -E, -H, and -P lines released since are all risc-v.

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

#112

Post by tliltocatl »

ltbarcly3 wrote: post #65

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.

> I'm starting to get the feeling that there is something fundamentally broken in the RISC-V specification that fundamentally limits performance.

RISC-V is an objectively bad ISA design (a resell of MIPS dropping some of the most ominous features, then trying fix the code density issue with billions of extensions), but x86 is way worse and it didn't prevent Intel from making performant implementations. And RISC-V is certainly not bad in the way that would limit performance (well, maybe code density, but it's not the major issue).

The reality is, ISA matters very little for CPU performance. What really matters a lot is the memory subsystem and interconnect. I. e. good DRAM controllers IP are pricey - way more pricey than ARM cores AFAIK. Not a problem unique to RISC-V - i. e. Altera memory controllers used to be shit as well, not sure if Intel changed anything.

And another issue - there doesn't seem to be all that much money in CPUs any more. Look at ARM's history with high-performance sector.

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

#113

Post by dismalaf »

PaulRobinson wrote: post #67

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.

Nvidia has shipped over 3 billion RISC-V cores: https://riscv.org/blog/how-nvidia-shipped-one-billion-risc-v...

Tenstorrent is shipping RISC-V chips made on Samsung 3nm node: https://tenstorrent.com/newsroom/tenstorrent-sets-new-perfor...

Note that Jim Keller (heavyweight in the world of CPU architecture) is their CEO.

Qualcomm recently acquired a RISC-V startup. https://www.qualcomm.com/news/releases/2025/12/qualcomm-acqu...

Plus they're eating ARM for low-end devices (IoT).

RISC-V is going to become the Linux of chips, for the same reasons Linux became big. It might honestly come even faster as Microsoft isn't tethered to any chipmaker these days.

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

#114

Post by dismalaf »

hmry wrote: post #85
rzerowan wrote: post #76

Earlier quoted context omitted.

I believe in microcontrollers its already pretty ubiquitous , see their utilisation by WesternDigital with their SwerV core thats already shipping since 2019. At speeds and complexity comparable to desktop/server cores from Intel/AMD they are still lagging in perf though improving as more cores get deployed. Also to add into the mix the whole geopolitics with non-US players hedging. So potential is there will just de…

Non-US hedging will be big for RISC-V in the future, but the geopolitics can also cut the other way. E.g. US banning US companies from using Chinese RISC-V chips, to protect their domestic players. Especially now that intel is partially state-owned.

Qualcomm, AMD and Nvidia are heavily investing in RISC-V, Intel's foundry produces RISC-V chips and the US government investment is largely because Intel has a SOTA foundry. Not just x86.

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

#115

Post by mort96 »

invokestatic wrote: post #88
rzerowan wrote: post #76

Earlier quoted context omitted.

I believe in microcontrollers its already pretty ubiquitous , see their utilisation by WesternDigital with their SwerV core thats already shipping since 2019. At speeds and complexity comparable to desktop/server cores from Intel/AMD they are still lagging in perf though improving as more cores get deployed. Also to add into the mix the whole geopolitics with non-US players hedging. So potential is there will just de…

Firmware & systems dev here, ARM still dominates in the microcontroller space. There are some niche offerings from major vendors but again they are niche. Espressif is the sole exception with their newer ESP32-C series chips, but they can get away with it due to their massive HAL. ARM Cortex is still the standard because there’s a decade or two of inertia behind it. An apt comparison would be C vs Rust. Yes, Rust may…

It's not just Espressif's ESP32-C series, it's all their new offerings. The low-end ESP32-C2, C3, C5, C6 and C61, the high-end ESP32-P4, the base ESP32 replacement "all-rounder" ESP32-S21, the ESP32-H2. The last Xtensa-based MCU they released was the S3, 6 years ago.

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

#116

Post by Veserv »

pjmlp wrote: post #26
rwmj wrote: post #12

Earlier quoted context omitted.

There's zero chance CHERI will go anywhere, I wouldn't worry about it.

ARM and Microsoft care about CHERI, that is enough to eventually make it happen, even if only on high integrity computing, like folks that still care about paying for Unisys ClearPath MCP. Or eventually have its ideas come into the evolution of ARM MTE, Pluton, and Silicon, which increasingly becoming adopted, alongside the oldie SPARC ADI. It is the x86 linage that keeps getting it wrong on hardware memory tagging s…

Have they figured out how to implement free() yet?

Last I looked you need a garbage collector to deallocate at which point you might as well use Java which is actually designed for that use case.

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

#117

Post by ksec »

benj111 wrote: post #109
ksec wrote: post #107

Earlier quoted context omitted.

[flagged]

People criticise them all the time. Have you got any pertinent criticisms or is this all you have to say?

>People criticise them all the time

That is a very recent thing. And I have done enough of mine to push against the tide.

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

#118

Post by bee_rider »

pjmlp wrote: post #68
rwmj wrote: post #36

Earlier quoted context omitted.

However you can do what Airbus do and formally prove your C code and use a formally proven toolchain like compcert to compile it. Or you can take a performance hit and add bounds checking to the C code[1]. Aircraft systems are probably the best chance that CHERI has, and that's pretty niche, small runs and very expensive, and still better solved in software. [1] I literally wrote the paper on this back in 1996: https…

Most people on HN would run screaming away if they had to follow high integrity computing processes on their daily C programming. If they think programming with Modula-2 and Object Pascal is programming with a straightjacket, good luck with MISRA, Frama-C, DOD and ISO certifications for reliable C code.

I thought MISRA was fine, and I don’t really understand why people complain about it. At least as a Fortran programmer who had to dabble in some C, I found I could read and write MISRA C much more easily than the obfuscated nonsense that C programmers get up to without rules, haha. (Actually come to think of it, it could just be that the MISRA codebase was engineered from the beginning).

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

#119

Post by timhh »

pjmlp wrote: post #94
timhh wrote: post #75

Earlier quoted context omitted.

Is it valuable enough though. Looking at Google's stats Rust has several orders of magnitude fewer memory vulnerabilities even with `unsafe` (kind of the point). If C was at that level there's no way CHERI would have ever been proposed. There are two counter-arguments: 1. There's a lot of C/C++ code still out there. You can't rewrite it all. I'm not totally convinced by that though because, a) do you need to? Google…

The problem is that with LLVM, GCC, CUDA, Vulkan, POSIX, V8 and co, there will be lots of new C and C++ getting written as well. Even on OpenJDK and CLR side, as new language features allow to rewrite even more runtime code from C++ into Java and C#, there is still new runtime code getting written in C++. There is already clever tech for hardware memory tagging (SPARC ADI, and ARM MTE), CHERI is yet another way to ta…

There's no real need for LLVM, GCC or CUDA to be memory safe. POSIX libc is of course C by definition but libc's are normally extremely well tested, and it is possible to avoid libc entirely if you want.

V8 is actually a nice case for CHERI since you can easily sandbox the JIT'd code. If you were to just rewrite V8 in Rust then you wouldn't get that benefit (you can't run the borrow checker on generated assembly). I assume they have some other sandboxing methods instead though.

But in general if you think about things like V8, that's used on high performance application class consumer CPUs. It's going to be at least 10 years before anyone has one of those with CHERI (unless ARM changes its mind about Morello). I would not bet against V8 being ported to Rust before that.

As I said I think CHERI is great technology and I hope it does succeed, but it does seem like the business case for it is not as strong as it was just a few years ago.

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

#120

Post by pjmlp »

rwmj wrote: post #100
pjmlp wrote: post #96

Earlier quoted context omitted.

Yet to this day no major OS vendor, selling C and C++ compilers, has ever bothered with. Hardware memory tagging, via SPARC ADI, ARM MTE, CHERI has become a thing, before software based processes so far have failed adoption, and the OS vendors like Google, Microsoft, Apple, Oracle, rather go with hardware approach.

Major OS vendors have added loads of hardening to their C compilers. Not bounds checking specifically (because even if the overhead was only 20% that would be too high) but tons of other stuff such as: stack canaries, control flow integrity, hardened string functions, ASLR, zeroing uninitialized auto variables, forced warnings, linker hardening. These are added as standard in all decent Linux distros today. Probably…

Kind of, because to this day it has been a quixotic battle for devs to use them at scale.

Those OS vendors rather push for Swift, Java/Kotlin, C#, and Rust instead.

Alongside ARM MTE, Pluton, SPARC ADI.

Also, all those hardening measures and lack of bounds checking could have been solved with WG14 papers, nowhere to be found. C isn't set in stone.

Post reply on HN