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

71–80 of 142 posts

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

#71

Post by [deleted] »

rwmj wrote: post #31
pjmlp wrote: post #26

Earlier quoted context omitted.

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…

ARM and Microsoft don't "care" enough to do anything beyond a bit of token research. Maybe there will be some extremely niche chips one day, or maybe not because the problem can be solved 90% as well in software on ordinary hardware.

[deleted]

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

#72

Post by pjmlp »

sph wrote: post #39
mort96 wrote: post #35

Earlier quoted context omitted.

I haven't exactly seen an outpouring of consumer demand for CHERI.

Is there an outpouring of hardware offer for CHERI? I'm a random nobody, but I'm sitting on this design for a message-passing platform that can only truly perform in a world where processes live in a single address space, which requires CHERI hardware to be feasible (or secure) at all. CHERI would open many doors in operating system design and security, and it's stagnant because it's not a real thing yet, there's no…

Tell ARM about it, https://cheri-alliance.org/discover-cheri/cheri-products/mor...

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

#73

Post by timhh »

unprovable wrote: post #46
jhvkjhk wrote: post #10

> “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 winni…

I've been trying to get access to CHERI for quite a while - I have a background in hardware security so was very curious to have a play. But only 'approved partners' are allowed to have access... guessing even in projects like this, Security through Obscurity still reigns.

> Security through Obscurity still reigns.

That's not the case at all. The spec is developed in the open: https://riscv.github.io/riscv-cheri/

If you want to run CHERI code, it's true that silicon isn't easily available, but that's simply because it takes time. Various companies are working on it (Codasip, SCI, Secqai, lowRISC, etc.).

But you don't need silicon to run CHERI code. There are various emulators available that support it. There's QEMU: https://github.com/CHERI-Alliance/qemu There's also the RISC-V Sail model, this is the latest CHERI branch: https://github.com/CHERI-Alliance/sail-riscv (unfortunately it is a bit behind upstream master, and also a bit behind the latest CHERI spec which is still evolving).

There are also a few open source chips available that implement CHERI which you can run in Verilator or an FPGA. For example cheriot-ibex https://github.com/microsoft/cheriot-ibex . This is actually a variant of CHERI for microcontrollers called CHERIoT. Long story but the plan is to merge CHERIoT back into CHERI so it is just a "profile" of CHERI.

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

#74

Post by pjmlp »

crote wrote: post #57
pjmlp wrote: post #30

Earlier quoted context omitted.

It still requires Android to care about RISC-V, plenty of NDK stuff. https://developer.android.com/ndk/guides/abis Then OSes like HarmonyOS and HarmonyOS NEXT aren't even that relevant outside China. Finally the chips have to deliver in performance, to actually provide good mobile devices.

> Finally the chips have to deliver in performance, to actually provide good mobile devices. Or the other way around: the low-end market wants to adopt it due to lower licensing fees, so Android is incentivized to support RISC-V or risk losing that market to a competing platform. Especially in markets with a God App like Wechat something in-between feature phone and smartphone won't be a very hard sell. RISC-V adopti…

If the chips aren't fast enough to run a JIT and AOT compiler, a concurrent copying generational GC, along with a modern Vulkan implementation, no one would care, they would be better with feature phones at that point.

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

#75

Post by timhh »

pjmlp wrote: post #23
rando1234 wrote: post #20

Earlier quoted context omitted.

Yeah, I feel like Rust has killed Cheri.

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 has shown that just writing new code in Rust is very effective, and b) AI is actually pretty decent at porting from C/C++ to Rust so maybe you can?

2. CHERI also allows really strong and fine grained compartmentalisation. This is absolutely fantastic for robustness, supply chain security and so on. If you want the absolute 100% most secure code possible, then Rust + CHERI with compartmentalisation is basically the best thing you can do. (Though Rust compartmentalisation is still not actually ready yet; it's in progress though.) That's really great but I'm not sure that level of security is needed by most projects, and also I think you can get pretty good compartmentalisation (though definitely not CHERI level) by doing something like what Xous does (basically isolation with processes/virtual memory, combined with the ability to call functions in other processes; IIRC Hubris OS does something similar).

CHERI is clever tech though and it would definitely be a boon for RISC-V if it succeeds.

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

#76

Post by rzerowan »

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.

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 depend on what will be the base case like Windows was for Intel.

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

#77

Post by Someone »

diamondlovesyou wrote: post #50
seastarer wrote: post #47

Earlier quoted context omitted.

You can try to re-vectorize the code for larger vector size.

Not if you can't prove anti-aliasing properties, which wasm doesn't carry.

I don’t think the OP is starting from WASM code; they’re starting from a language with SIMD primitives that map closely to those of WASM. There, you often have information to prove function arguments do not alias.

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

#78

Post by ykonstant »

modulovalue wrote: post #8

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…

>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 would also be interested in RISC-V emulators etc.

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

#79

Post by ykonstant »

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.

For the record, I found programming in MISRA C guidelines really fun; but then again, I did it out of personal interest. If I had to do it professionally, I guess the pressure would be less pleasant.

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

#80

Post by 0x000xca0xfe »

pjmlp wrote: post #74
crote wrote: post #57

Earlier quoted context omitted.

> Finally the chips have to deliver in performance, to actually provide good mobile devices. Or the other way around: the low-end market wants to adopt it due to lower licensing fees, so Android is incentivized to support RISC-V or risk losing that market to a competing platform. Especially in markets with a God App like Wechat something in-between feature phone and smartphone won't be a very hard sell. RISC-V adopti…

If the chips aren't fast enough to run a JIT and AOT compiler, a concurrent copying generational GC, along with a modern Vulkan implementation, no one would care, they would be better with feature phones at that point.

They are already. I've got the Spacemit K3 and it is a bit below Sandy Bridge single-core speed - so nothing spectacular - but fast enough for everyday desktop use. And way faster than my old budget smartphone's SoC.

Yes RISC-V has not caught up to modern x86/ARM CPUs like Zen 5, Snapdragon or Apple but still fast enough for modern browsers and most software in general.

Already existing RISC-V CPUs are certainly fast enough to build entry level smartphones. It's probably just a matter of time (3-5 years maybe?) until some Chinese company does it.

Post reply on HN