sail-riscv VS riscv-gnu-toolchain

I've been doing a lot of work with Sail (not SAIL btw) and I'm not sure I agree with the points about it.

There's already a way to extract functions into asciidoc as the author noted. I've used it. It works well.

The liquid types do take some getting used to but they aren't actually used in most of the code; mostly for utility function definitions like `zero_extend`. If you look at the definition for simple instructions they can be very readable and practically pseudocode:

https://github.com/riscv/sail-riscv/blob/0aae5bc7f57df4ebedd...

A lot of instructions are more complex or course but that's what you get if you want to precisely define them.

Overall Sail is a really fantastic language and the liquid types really help avoid bugs.

The biggest actual problems are:

1. The RISC-V spec is chock full of undefined / implementation defined behaviour. How do you capture that in code, where basically everything is defined. The biggest example is probably WARL fields which can do basically anything. Another example is decomposing misaligned accesses. You can decompose them into any number of atomic memory operations and do them in any order. E.g. Spike decomposes them into single byte accesses. (This problem isn't really unique to Sail tbf).

2. The RISC-V Sail model doesn't do a good job of letting you configure it currently. E.g. you can't even set the spec version at the moment. This is just an engineering problem though. We're hoping to fix it one day using riscv-config which is a YAML file that's supposed to specify all the configurable behaviour about a RISC-V chip.

I definitely agree about the often wooly language in the spec though. It doesn't even use RFC-style MUST/SHOULD/MAY terms.

The official formal specification of the Vector Extension has just been merged into the Golden RISC-V model:

https://github.com/riscv/sail-riscv/commit/c90cf2e6eff5fa4ef...

the retired instruction counters when written by software.

Funnily enough the Sail model had this bug too! https://github.com/riscv/sail-riscv/issues/256

> loose specification of the RISC-V ISA.

This is being worked on with the Sail model [1]. In order for a RISC-V extension to be ratified it ought to be implemented in Sail. The understanding is also that the RISC-V ISA manual should be built with code snippets from the Sail model (similar to how the Arm Arm is build from ASL definition). The main issue is a lack of people willing and able to write Sail for RISC-V. But that is beginning to change, since RISC-V member companies are increasingly use Sail. As an example, the RISC-V exception type is defined in [2]. Is that precise enough for you?

[1] https://github.com/riscv/sail-riscv

[2] https://github.com/riscv/sail-riscv/blob/master/model/riscv_...

>it allows to formally verify the correctness of a particular ISA

That must be hypothetical. Functionalness of the language doesn't make anything that is written in it automatically subject to formal verification. (mechanized or pen and paper). What kind of correctness properties does it actually allow to formally verify? I understand if it was the F* language, which is a full blown dependently typed proof checker, but with F#, which is defined by the implementation and 300 page English spec, I don't think you can verify anything interesting. As far as I know F# itself doesn't have mechanized formal semantics and its type system could be unsound.

https://github.com/mit-plv/riscv-coq and https://github.com/riscv/sail-riscv (don't know how complete they are) approaches actually allow to formally (mechanically) verify riscv properties.

I guess you will also use Spike and the Sail model for RISC-V.

Doing something leveraging the SAIL model would be valuable, as that's the official formal model: https://github.com/rems-project/sail-riscv

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.