Live data from Hacker News

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

eetimes.com

21–30 of 142 posts

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

#21

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…

You can buy a RISC-V mainboard for the Framework Laptop, and it's relatively cheap (£170)

https://frame.work/gb/en/products/deep-computing-risc-v-main...

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

#22

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…

> 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.

On the one hand, this will be quite straight forward, but on the other hand quite disappointing.

Afaik Dart has a 128-bit only SIMD abstraction (so not performance portable by default). Since the base "V" extension mandates a mininum vector length of 128-bit, you can trivially make codegen work for all vector length, by simply setting vl to 128/elementwidth.

But as with x86, if your native hardware vector length is larger than 128-bit, you leave performance on the table.

> 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"?

I'd recommend using qemu for initial testing.

Hardware wise, the cheapest option is the orange pi rv2, which has 8 SpacemiT X60 cores, which are in-order and support 256-bit RVV. The Zhihe A210 is also interesting, but way to expensive for what it is.

If you have a higher budget, I'd recommend the SpacemiT K3, which is the fist RISC-V SBC with RVA23 support. It is has 8 SpacemiT X100 4-wide out-of-order cores, with 256-bit RVV.

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

#24
post #12

Earlier quoted context omitted.

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

Yeah, I feel like Rust has killed Cheri.

Do you have more details on why ? I just found stuff like: https://cheri-alliance.org/discover-cheri/rust-and-cheri/ Or https://rust.cheriot.org/2026/02/15/status-update.html

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

#25
post #21

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…

You can buy a RISC-V mainboard for the Framework Laptop, and it's relatively cheap (£170) https://frame.work/gb/en/products/deep-computing-risc-v-main...

No don't buy this one, it doesn't support RVV. Their newer ones do, but those are a lot more expensive.

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

#26
post #12
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…

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 solutions.

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

#27

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…

[deleted]

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

#28

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…

OrangePi RV2 might qualify for fun?

https://www.phoronix.com/news/Ubuntu-Linux-On-OrangePi-RV2

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

#29
post #23

Earlier quoted context omitted.

Yeah, I feel like Rust has killed Cheri.

CHERI is valuable even for unsafe Rust code.

The problems with CHERI are not whether it's technically good or not, it's organizational. It's an academic project that requires everyone to boil the ocean. They tried to get ARM interested and that didn't go anywhere and now they're trying to get RISC-V interested. But they haven't addressed any of the problems of why manufacturers would ever make a complex and completely incompatible chip for a problem that they (the manufacturers) don't have and don't care about, that can probably be solved 90% as well in software.

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

#30
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.

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.

Post reply on HN