- RISC-V is heavily used in embedded applications everywhere, to the point that Arm has announced they're stopping developing the Cortex-M line and sticking with what they currently have
- at least in the case of China and Russia, they already have machines using ISAs they developed and own themselves with higher performance than currently-available RISC-V
- RISC-V is not a "CPU technology" (that is, CPU micro-architecture) or a chipmaking technology. It's just a language for writing recipes, and says nothing at all about the medium or technology used to record and distribute and follow those recipes.
- within the next 12-24 months, RISC-V chips designed and made in the West will match or exceed those designed in China as many top CPU designers joined or founded RISC-V companies around 2021/2 (and Intel's ex "Royal Core" team in 2024).
All RISC ISAs are basically the same thing as far as compiler optimisation is concerned, and there is 40 years of work into that already.
I can't see any reason why the father of Zen and the designer of the M1 can't make a core for the simpler RISC-V ISA with basically the same (or better) µarch than the M1.
I don't see any rationale or explanation of the thinking. Is it purely an exercise? Exploration? Is there some algorithm space in which it has an advantage over binary?
Is there a compiler?
How does it compare on Dhrystone or Coremark per LUT compared to a RISC-V core of similar size on the same FPGA?
There are many reasons.
The main one is that no architecture exists that models such a complex ternary processor.
At most, there are "on paper" implementations of much less complex architectures; no one has addressed the problem at this level.
Having a complete architecture and its hardware implementation now allows us to start developing software on something other than an emulator.
> ----
I don't see any rationale or explanation of the thinking. Is it purely an exercise? Exploration? Is there some algorithm space in which it has an advantage over binary?
> -----
No, it's a processor that's available now, both the current hardware implementation (on FPGA) and the Verilog/VHDL description for implementation on other architectures (ASIC?), as well as the specifications made available under license.
>----
Is there a compiler?
>----
Hmm, but I mentioned it in the paper; currently, a working cross-assembler (obviously) and a high-level language based on Rust are being designed/built.
>----
How does it compare on Dhrystone or Coremark per LUT compared to a RISC-V core of similar size on the same FPGA?
>----
This is an interesting question; the answer is: currently, no.
We intend to provide (soon) comparative tests of this type.
The "G" extension for everything you want to run shrink-wrapped binaries on a standard OS has been there since the May 7 2014 "User Level ISA, Version 2.0", which is before RISC-V started to be promoted outside of Berkeley e.g. at Hot Chips 26 in August 2014, and the first RISC-V workshop in January 2015 in Monterey.
The name "G" has morphed into now (along with the C extension) being called "RVA20", which led to "RVA22" and "RVA23", but the principle is unchanged.
"An integer base plus these four standard extensions (“IMAFD”) is given the abbreviation “G” and provides a general-purpose scalar instruction set. RV32G and RV64G are currently the default target of our compiler toolchains."
The "G" extension for everything you want to run shrink-wrapped binaries on a standard OS has been there since the May 7 2014 "User Level ISA, Version 2.0", which is before RISC-V started to be promoted outside of Berkeley e.g. at Hot Chips 26 in August 2014, and the first RISC-V workshop in January 2015 in Monterey.
The name "G" has morphed into now (along with the C extension) being called "RVA20", which led to "RVA22" and "RVA23", but the principle is unchanged.
"An integer base plus these four standard extensions (“IMAFD”) is given the abbreviation “G” and provides a general-purpose scalar instruction set. RV32G and RV64G are currently the default target of our compiler toolchains."
> RISC-V hardware with slow misaligned mem ops does exist to non-insignificant extent
Only U74 and P550, old RV64GC CPUs.
SiFive's RVA23 cores have fast misaligned accesses, as do all THead and SpacemiT cores.
I can't imagine that all the Tenstorrent and Ventana and so forth people doing massively OoO 8-wide cores won't also have fast misaligned accesses.
As a previous poster said: if you're targeting RVA23 then just assume misaligned is fast and if someone one day makes one that isn't then sucks to be them.
P550 is, like, what, only a year old? I suppose there has been some laughing at it at least.
Also Kendryte K230 / C908, but only on vector mem ops, which adds a whole another mess onto this.
I'd hope all the massive OoO will have fast misaligned mem ops, anything else would immediately cause infinite pain for decades.
But of course there'll be plenty of RVA23 hardware that's much smaller eventually too, once it becomes a general expectation instead of "cool thing for the very-top-end to have".
I do agree that it'd be reasonable to just assume fast misaligned ops, but for whatever reason gcc and clang just don't, and that's what we have for defaults.
It has take a while for this core to appear in an SoC suitable for SBCs, as Intel was originally announced as doing that and got as far as showing a working SoC/Board at the Intel Innovation 2022 event in September 2022.
Someone who attended that event was able to download the source code for my primes benchmark and compile and run it, at the show, and was kind enough to send me the results. They were fine.
For reasons known only to Intel, they subsequently cancelled mass production of the chip.
ESWIN stepped up and made the EIC7700X, as used in the Milk-V Megrez and SiFive HiFive Premier P550, which did indeed ship just over a year ago.
But technically we could have had boards with the Intel chip three years ago.
Heck we should have had the far better/faster Milk-V Oasis with the P670 core (and 16 of them!) two years ago. Again, that was business/politics that prevented it, not technology.
> No, it was released to customers in June 2021, almost five years ago.
Ah, okay. (still, like, at least a couple decades newer than the last x86-64 chip with slow unaligned mem ops, if such ever existed at all? Haven't heard of / can't find anything saying any aarch64 ever had problems with them either, so still much worse for the RISC-V side).
Well, I suppose we can hope that business/politics messes will all never happen again and won't affect anything RVA23.
> I do agree that it'd be reasonable to just assume fast misaligned ops, but for whatever reason gcc and clang just don't, and that's what we have for defaults.
This very much has a "for now" on it. Once there is actually widespread hardware with the feature, I would be very surprised if the compilers don't update their heuristics (at least for RVA23 chips)
Indeed we shall hope heuristics update; but of course if no compilers emit it hardware has no reason to actually bother making fast misaligned ops, so it's primed for going wrong.
hardware devs traditionally have been pretty good at helping the compiler teams with things like this (because its a lot cheaper to improve the compiler than your chip).
It's a good solid reliable board, but over three years old at this point (in a fast-moving industry) and the maximum 8 GB RAM is quite challenging for some builds.
Binutils is fine, but on recent versions of gcc it wants to link four binaries at the same time, with each link using 4 GB RAM. I've found this fails on my 16 GB P550 Megrez with swap disabled, but works quickly and uses maybe 50 or 100 MB of swap if I enable it.
On the VisionFive 2 you'd need to use `-j1` (or `-j2` with swap enabled) which will nearly double or quadruple the build time.
Or use a better linker than `ld`.
At least the LLVM build system lets you set the number of parallel link jobs separately to the number of C/C++ jobs.
> I've found this fails on my 16 GB P550 Megrez with swap disabled but works quickly and uses maybe 50 or 100 MB of swap if I enable it.
I see, I don't have a Megrez at my desk, only in the build system. I only have P550 as my "workhorse".
PS: I made a typo above - the P550 I was referring to was the SiFive "HiFive Premier P550". But based on your HN profile text, you must've guessed it as much :)
- RISC-V is heavily used in embedded applications everywhere, to the point that Arm has announced they're stopping developing the Cortex-M line and sticking with what they currently have
- at least in the case of China and Russia, they already have machines using ISAs they developed and own themselves with higher performance than currently-available RISC-V
- RISC-V is not a "CPU technology" (that is, CPU micro-architecture) or a chipmaking technology. It's just a language for writing recipes, and says nothing at all about the medium or technology used to record and distribute and follow those recipes.
- within the next 12-24 months, RISC-V chips designed and made in the West will match or exceed those designed in China as many top CPU designers joined or founded RISC-V companies around 2021/2 (and Intel's ex "Royal Core" team in 2024).
reply