riscv-isa-sim VS qemu

Someone correct me if I'm wrong, but Spike is considered the gold standard for RISV-V simulation, in terms of support for extensions and overall correctness. As I understand it, QEMU is faster and easier to use for day-to-day for general software development.

Spike is an RISC-V instruction set simulator: https://github.com/riscv-software-src/riscv-isa-sim

I really like the source code for the Spike RISC-V ISA Simulator. It's not very heavily commented, though, so you really need to read the code.

If you want to run bare metal with no RTOS, it should be possible, but you will need to replace the main startup program (https://github.com/riscv-software-src/riscv-isa-sim/blob/master/spike_main/spike.cc) with some program to set up the hardware and instantiate the simulator, load the OS image etc and then have a decent runtime environment to that supports malloc() etc and redirect IO to serial or flash memory etc. There is a bit of work you would need to do.

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

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