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

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.

The first question has to be: why?

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?

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

pp 4-5 in

https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-...

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

pp 4-5 in

https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-...

No, it was released to customers in June 2021, almost five years ago.

https://www.sifive.com/press/sifive-performance-p550-core-se...

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.

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.

Less than 7 years from ratification of the initial RV{32,64}GC spec.

Less than 5 years from the first mass-produced roughly original Raspberry Pi level $100 SBC: AWOL Nezha, shipped June 2021.

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.

http://hoult.org/primes.txt

> newer gcc versions have significantly better optimization passes

So what you're saying is that with a modern compiler RISC-V would win by even more?

TBH I doubt much has changed with register allocation on register-rich RISC ISAs since 2018. On i386, yeah, quite possible.

Also MIPS code is much larger.

x86_64:

    localhost:~# time gcc -O primes.c -o primes
    real    0m 3.18s
    user    0m 1.30s
    sys     0m 1.47s
    localhost:~# time ./primes
    Starting run
    3713160 primes found in 456995 ms
    245 bytes of code in countPrimes()
    real    7m 37.97s
    user    7m 36.98s
    sys     0m 0.00s
    localhost:~# uname -a
    Linux localhost 6.19.3 #17 PREEMPT_DYNAMIC Mon Mar  9 17:12:35 CET 2026 x86_64 Linux

    localhost:~# time gcc -O primes.c -o primes
    real    0m 2.08s
    user    0m 1.43s
    sys     0m 0.64s
    localhost:~# time ./primes
    Starting run
    3713160 primes found in 348424 ms
    301 bytes of code in countPrimes()
    real    5m 48.46s
    user    5m 37.55s
    sys     0m 10.86s
    localhost:~# uname -a
    Linux localhost 4.12.0-rc6-g48ec1f0-dirty #21 Fri Aug 4 21:02:28 CEST 2017 i586 Linux

    [root@localhost ~]# time gcc -O primes.c -o primes
    real    0m 2.08s
    user    0m 1.13s
    sys     0m 0.93s
    [root@localhost ~]# time ./primes
    Starting run
    3713160 primes found in 180893 ms
    216 bytes of code in countPrimes()
    real    3m 0.90s
    user    3m 0.89s
    sys     0m 0.00s
    [root@localhost ~]# uname -a
    Linux localhost 4.15.0-00049-ga3b1e7a-dirty #11 Thu Nov 8 20:30:26 CET 2018 riscv64 GNU/Linux

Note: quite different gcc versions, with x86_64 being 15.2.0, x86 9.3.0, and riscv64 7.3.0.

[1] http://hoult..rg/primes.txt

Read the original papers on them.

http://li.mit.edu/Stuff/CNSE/Paper/Hanson90.pdf

https://www.jstor.org/stable/3216893

https://mason.gmu.edu/~rhanson/insiderbet.pdf

It keeps nagging me to update to Tahoe.

Oh ... I just checked, and I could update to 14.8.4. Maybe that's safe.

The 6502 is not very different with a very small number of registers and Zero Page being used for most of what a modern machine would use registers for. For example (unlike the Z80) there is no register-to-register add or subtract or compare -- you can only add/sub/cmp/and/or/xor a memory location to the accumulator. Also, pointers can only be done using a pair of adjacent Zero Page locations.

As long as you were using data in those in-RAM registers the TI-99/4 was around four times faster than a 1 MHz 6502 for 16 bit arithmetic -- and with a single 2-byte instruction doing what needed 7 instructions and 13 bytes of code on 6502 -- and it was also twice as fast on 8 bit arithmetic.

It was just the cheap-ass main memory (and I/O) implementation that crippled it.