riscv-gnu-toolchain VS riscv-gnu-toolchain

> no absurdely and grotesquely massive and complex compilers anywhere

Absence of evidence is not evidence of absence, and anyway there's not even an absence: https://github.com/riscv-collab/riscv-gnu-toolchain https://llvm.org/docs/RISCVUsage.html

> feature creeps on computer language syntax nowhere to be found

At least one of us is very confused, and in case it's me, how do language details matter to RISC-V?

I then looked at the .cargo/config.toml provided by the guide and saw that it wasn't actually statically compiling the code. After a bit of tinkering and building my own toolchain from here, I ended up with this config.toml file:

b) collabriscv - essentially gcc 12.2 + binutils master/2.40 as per https://github.com/riscv-collab/riscv-gnu-toolchain

Or would it be better to take what is in https://github.com/riscv-collab/riscv-gnu-toolchain which is gcc 12.2 and start from there?

I'm not able to build https://github.com/riscv-collab/riscv-gnu-toolchain.git like this:

That shouldn't be news.

Other than the CanMV-K230 (Kendryte K230, single 1.6 GHz C908 core implementing RVV) which just started shipping in the last two weeks, every RISC-V board with RVV has either C906 or C910 cores which implement draft 0.7.1.

Those CPU cores were announced in mid 2019 (when RVV 0.7.1 was the current draft) and boards using them start arriving in mid to late 2021.

RVV 1.0 boards will start arriving in force next year, probably starting with the StarFive JH8110 SoC, and (apparently, though I'm not sure I believe it) an update of the SG2042 in the Pioneer, and also the 16 core (but faster cores) SG2380.

> Do you happen to have the name of the gcc branch

The branch has been deleted from the official repo. I have a snapshot on my github:

https://github.com/brucehoult/riscv-gnu-toolchain

Note that it is primarily binutils which understands RVV 0.7.1. GCC understands it only to the extent of accepting "v" in "-march" and passing the right flags to the assembler. This enables using the gcc driver to build .s files and inline RVV asm in C. There is no support for RVV intrinsic functions or auto-vectorisation.

It's also a somewhat old gcc. I use it to build .o files from assembly language, and then link them with C compiled by a newer gcc or llvm. Or not, most of the time gcc 9 is fine.

THead have RVV 0.7.1 support in newer gcc, but I haven't been tracking that closely.

The TH1520 has much faster memcpy speeds at every level of cache and DRAM.

https://hoult.org/JH7110_memcpy.txt

https://hoult.org/JH7110_memcpy.txt

And yet ... both Richard Jones at Fedora and I have found that the VisionFive 2 is actually slightly faster at building software packages!

My result was that building the same binutils + gcc + newlib snapshot (an old one with RVV 0.7.1 support)...

https://github.com/brucehoult/riscv-gnu-toolchain

... the VisionFive 2 takes 108 minutes while the Lichee Pi 4A takes 122 minutes.

That's with the supplied fan on the LPi4A (and confirmed it's not throttling) and no cooling at all on the VisionFive 2. I used the same Samsung external USB3 SSD on both -- the VisionFive 2 gets slightly faster transfer speeds (IIRC 190 MB/s vs 160) with that, but that's not enough to matter: just 12s difference on the time to tar up the source directory, compared to a 14 minute build time difference. Both have enough RAM to cache everything anyway.

> VF2 GPU: IMG BXE-4-32 Lichee Pi: ?? Anyone?

BXM-4-64

I've also found the 1.5 GHz in-order VF2 does remarkably well vs the 1.85 GHz OoO LPi4A on software build tasks, though not as extreme as Richard shows.

I'm lazy and using the original Image-55 on my 8 GB VF2, and the Debian that came preloaded in the eMMC on the LPi4A. My mass-production LPi4A arrived yesterday, I haven't tried it yet, tests are on the beta board that arrived a couple of months ago.

On pure CPU core + L1 cache tests (e.g. https://hoult.org/primes.txt) the LPi4A is considerably faster.

The LPi4A is also much faster on memcpy tests.

https://hoult.org/TH1520_memcpy.txt

https://hoult.org/JH7110_memcpy.txt

My build test is an RVV 0.7.1-enabled snapshot of the gnu toolchain (gcc 9.2) that I use on the TH1520 and SG2042. Newlib, non-multilib (just rv64gcv) build. I used the same Samsung 2 TB external USB3 SSD drive for src/build trees on both boards. https://github.com/brucehoult/riscv-gnu-toolchain

VF2:

real 107m52.116s

To build rvv programs I use brucehoults rvv 0.7.1 toolchain and some assembly macros, so I can write a subset of rvv 1.0 that I can run on rvv 0.7.1: https://github.com/brucehoult/riscv-gnu-toolchain https://github.com/camel-cdr/rvv-d1/blob/main/rvv-rollback.S

I'm using a rvv 0.7.1 toolchain, which doesn't support the rvv 1.0 mnemonics.

Step 1. Build the RISC-V GNU toolchain suitable for compiling and assembling RVV 0.7.1 instructions, and that would be https://github.com/brucehoult/riscv-gnu-toolchain. For grins I built this on a RISC-V machine, the Unmatched. It took a few hours, but there's something sublime about using RISC-V everywhere you can.