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

There are several RISC-V machines. In the microcontroller world it's becoming more and more usual, but those won't have RVV. SpacemiT K3 based machines are probably your best bet when it comes to RISC-V processors with SIMD support. There are several manufacturers: Milk-V with the Jupiter II, Sipeed, Banana Pi, ...

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

There are various emulators available that support RVV but they aren't going to be especially useful for benchmarking/profiling.

So you can write code that works, but it's probably a few more years still until high performance RISC-V cores are easily available for profiling RVV code and finding the best code.

Progress is steady though - it will happen soon. It's not one of those "year of desktop Linux" things.

OrangePi RV2 might qualify for fun?

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

Except that ARM is pretty much theirs, or at least they have complete control over it, which they never did for any previous arch. They also handle chip production directly. Nothing in RISC-V could be worth more than what they can already wring out of ARM without having to migrate.

What a circular argument that avoids answering the question. How does "it needs a new base ISA" address the concern about "might fracture the open-source community" even one bit? Why does the "journalist"/writer call that reply "a devoted defense", in what world is that any sort of defense?

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.

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

Krste wasn't even saying anything controversial. It's obvious that manufacturers will use the cheapest (free) least legally entangled option, and that this adoption will happen first amongst those with the tightest margins. And - Clayton's law[1] - it will eventually extend to the rest of the market (albeit over a very long time).

https://en.wikipedia.org/wiki/Clayton_Christensen

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 to transition away from ARM.

Now, embedded markets are different but they've always been different and the number of embedded programmers is dwarfed by non embedded programmers and regular users will for a long time never install an app on RISC-V.

It's an interesting journey, let's see where it takes us in 20 years.

We still have to see a RISC-V implementation that comes even close to the performance of ARM

Can you elaborate on

> But it also allows for a lot of hardware to be locked down just like ARM

I thought Apple has a special deal with ARM as they were an early investor?

5 years ago there was a req on the Apple job site for engineers familiar with RISC-V.

https://riscv.org/blog/apple-exploring-risc-v-hiring-risc-v-...

What options are those? Anything they do that makes ARM better/cheaper for consumers makes RISC-V a win, even if it never reaches mainstream adoption.

Risc-v bexomomg a competitor is bemeficial for ARM's clients as it gives them leverage in price negotiations, which they don't have at the moment.