qemu VS sail-riscv

https://gitlab.com/qemu-project/qemu/-/blob/master/hw/scsi/s...

QEMU's IOThreads allow the user to configure the threads and get something similar to thread per core architecture. But if 1 thread becomes a bottleneck, then some form of thread synchronization is needed again even with thread per core architecture. Some problems can be parallelized and they work well with thread per core.

Add `ENV ERL_FLAGS="+JPperf true"` to your Dockerfile and it will build just fine cross platform. The flag just changes some things during build time and won’t affect runtime performance.

[1] https://gitlab.com/qemu-project/qemu/-/issues/1034

> I don't know how rdcycle works on qemu.

That's a good question! I had to look it up myself ...

Obviously qemu TCG isn't a cycle-accurate emulation. Using RDCYCLE / reading the corresponding CSR eventually calls https://gitlab.com/qemu-project/qemu/-/blob/69680740eafa1838... which calls cpu_get_host_ticks is basically an arch-independent wrapper around RDTSC.

So it just measures the time taken to run using RDTSC. Which I guess is what you would want (maybe?). It would measure the time taken to emulate the vector instruction in host instructions.

> This benchmark is more meant for developers to figure out how to vectorize algorithms effectively, as in which instructions to choose.

Absolutely, I'm not saying the qemu results would say anything very deep, but they're kind of interesting from the point of view of either optimizing qemu or if you have to use qemu because the hardware you want isn't available / isn't cheap enough.

I see the commits that started switch support from RVV 071 to 100 start here, https://gitlab.com/qemu-project/qemu/-/commit/9ec6622db30df1c00d863c1ffc33341f9e0a534d

>> https://gitlab.com/qemu-project/qemu/-/issues/1696 ]

> Can I please just get the detail in mail instead of having to go look at random websites?

Maybe it's me but if I did boot boot linux 292.612 times to find a bug, you might as well click a link to a repository of a major open source project on a major git hosting service.

Is it really that weird to ask people online to check a website? Maybe I don't know the etiquette of these mail lists so this is a geniune question.

Capstone is used[1] by QEMU as disassembly engine in debug logs and in monitor mode debugger, by the way, so it's in the scope of the RISE effort.

[1] https://gitlab.com/qemu-project/qemu/-/blob/master/disas/cap...

A user on the qemu bugtracker found a way to get the Intel Arc working across resets without crashing the host: Just don't passthrough the audio device of the GPU and everything works!

[1]https://gitlab.com/qemu-project/qemu/-/commit/3412d8ec9810b819f8b79e8e0c6b87217c876e32 [2]https://gitlab.com/alex.williamson/qemu/-/commit/9a6d1822a2bd55f5dee1aec1b6529ae57949d5ba.patch

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