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

91–100 of 142 posts

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

#91

Post by sph »

sylware wrote: post #87

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…

I have no experience with ARM, but after decades of x86, low-level programming or OS development with RISC-V is such a breath of fresh air. Writing a simulator from scratch for the base ISA is like two days of work tops. I am using RISC-V as the instruction set for a bespoke virtual machine: why design a ISA when RISC-V is simple and modular? Bonus: all compilers can now target my VM.

It will accumulate cruft over the years like all other platforms, but right now, it is a joy to work in.

It’s not just for fun, but I’m betting on it because I hope Europe will finally build its own chips, and there is a good likelihood they will choose RISC-V over ARM; expertise in that field for EU developers might soon be a plus.

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

#92

Post by leoc »

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.

Right: unfortunately it really is a bit much to dismiss CHERI as a no-hope effort to boil the seas if the alternative plan is to rewrite everything in formally verified C (even if you'd also try to move some of it into GC languages instead).

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

#93

Post by rwmj »

leoc wrote: post #92
pjmlp wrote: post #68

Earlier quoted context omitted.

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.

Right: unfortunately it really is a bit much to dismiss CHERI as a no-hope effort to boil the seas if the alternative plan is to rewrite everything in formally verified C (even if you'd also try to move some of it into GC languages instead).

The alternative is you use a compiler that adds bounds checking. It's possible to do this with C, with fine object granularity (even separate stack objects), and even preserve compatibility with existing non-bounds checked library code / system calls. When I did it back in 1996 there was a large overhead to doing that, but compilers can do much better these days. And anyway you have to compare the overhead to the cost of designing and building your own small run CPU and eshewing mainstream processors, which is also huge.

https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html

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

#94

Post by pjmlp »

timhh wrote: post #75
pjmlp wrote: post #23

Earlier quoted context omitted.

CHERI is valuable even for unsafe Rust code.

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 tame unsafety on our computing stacks.

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

#95

Post by ltbarcly3 »

snvzz wrote: post #84
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.

>and it's basically a joke. Look up the fab process node and die area of that chip, and think again.

I get that they can make super tiny cheap processors, but why isn't there one faster than a 4 year old raspberry pi?

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

#96

Post by pjmlp »

rwmj wrote: post #93
leoc wrote: post #92

Earlier quoted context omitted.

Right: unfortunately it really is a bit much to dismiss CHERI as a no-hope effort to boil the seas if the alternative plan is to rewrite everything in formally verified C (even if you'd also try to move some of it into GC languages instead).

The alternative is you use a compiler that adds bounds checking. It's possible to do this with C, with fine object granularity (even separate stack objects), and even preserve compatibility with existing non-bounds checked library code / system calls. When I did it back in 1996 there was a large overhead to doing that, but compilers can do much better these days. And anyway you have to compare the overhead to the cos…

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.

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

#97

Post by jingpostmedia »

0x000xca0xfe wrote: post #18
oblio wrote: post #13

Earlier quoted context omitted.

I wouldn't bet against software inertia. x86 only missed the mobile market because of multiple bad business decisions, otherwise ARM (and RISC architectures overall) would have been relegated to more decades as backwater architectures. There is nothing inevitable about anything as Apple controls its own silicon very tightly, Microsoft hasn't even really transitioned away from x86, and Android probably isn't very keen…

Chinese companies are really into RISC-V and China both builds and uses a lot of smartphones, I'm very sure we won't have to wait 20 years for regular users installing apps on RISC-V hardware.

[flagged]

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

#98

Post by LastTrain »

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.

There is a limit to how much of that the US can do without causing self inflicted damage.

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

#99

Post by sylware »

sph wrote: post #91
sylware wrote: post #87

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…

I have no experience with ARM, but after decades of x86, low-level programming or OS development with RISC-V is such a breath of fresh air. Writing a simulator from scratch for the base ISA is like two days of work tops. I am using RISC-V as the instruction set for a bespoke virtual machine: why design a ISA when RISC-V is simple and modular? Bonus: all compilers can now target my VM. It will accumulate cruft over th…

Yep, I guess we are many to see what's happening with RISC-V.

The most risk of cruft accumutation is in RVA... which is pursuing some level x86-64/ARM hardware compatibility.

That said intel APX/AVX10.2 is RISC-V for x86-64...

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

#100

Post by rwmj »

pjmlp wrote: post #96
rwmj wrote: post #93

Earlier quoted context omitted.

The alternative is you use a compiler that adds bounds checking. It's possible to do this with C, with fine object granularity (even separate stack objects), and even preserve compatibility with existing non-bounds checked library code / system calls. When I did it back in 1996 there was a large overhead to doing that, but compilers can do much better these days. And anyway you have to compare the overhead to the cos…

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 Windows too, I've no idea. There's a good summary here: https://best.openssf.org/Compiler-Hardening-Guides/Compiler-...

There are also bounds checking options for major C compilers so if you want to use it, you can, eg. -fbounds-safety or the various sanitize options in Clang.

Post reply on HN