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 guess it would be fun seeing all my SIMD-fiable use-cases become orders of magnitude faster on RISC-V, too, but I sadly never hear anything about machines that use RISC-V.
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.
https://frame.work/gb/en/products/deep-computing-risc-v-main...
> 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 winning the market.
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.
m68k (1984) > PPC (1994) - 10 years
PPC (1994) > x86 (2006) - 12 years
x86 (2006) > ARM64 (2020) - 14 years
ARM64 (2020) > ??? (2036) - 16 years
Go!
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.
I am cautiously optimistic about the future of RISC-V. It is likely to start biting at the heals of ARM in another 5 years or so, and having no licensing fees makes it very attractive in that sense. Qualcomm and Apple will be very interesting in avoiding as many ARM licensing fees as possible even if initially in embedded systems. But it also allows for a lot of hardware to be locked down just like ARM and so it might not be so great for the end users. Time will tell.
All I know is that I look for the seeing Apple Silicon 2 launching in 2036 using this stuff. ;)
> But it also allows for a lot of hardware to be locked down just like ARM
Yet there are still a lot of great projects around, that may end up in China grey market chip fabs (C950) at some point.
https://github.com/vortexgpgpu/vortex
ARM64/AArch64 is about constrained consistency, but most RISCV standards groups still fail to recognize their ISA version fragmentation was a serious mistake. So no, it won't exist outside niche use-cases until the kids stop arguing over what RISCV even means in a general end-user context (BOOM flags, RVA23, etc.) =3
https://riscv.org/blog/apple-exploring-risc-v-hiring-risc-v-...
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.
Not to mention the smartcard market which would mean billions of processors around the world.
And you cant rewritte 50 years of C in Rust. And even in Rust you can still run into various issues.
[1] I literally wrote the paper on this back in 1996: https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html
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 CPU one can buy that supports it in any way outside of research. Without CHERI, we're stuck with security models from the 1970s. Most people are fine with 1970s design, but the OS research world has been itching for something like this for decades.
How many tokens do you think that would cost?