Maybe a few months from now it may be able to run Linux as well. I had painted myself into a corner by processing execute segments in order to get more speed. However, I have currently found ways to have many execute segments, and before that I solved how to have memory traps without undue memory bandwidth pessimization. So, I have some hope that I may be able to support the Supervisor extension in the coming months, as all the puzzle pieces seems to be coming together. The emulator has had a fully virtual address space from the start, so the door has always been a little bit open.

I don't know if my plan is foolproof, but the plan is to trap on every page in page tables and if any changes are made, possibly followed by some kind of page table invalidation, I will be able to reconstruct the execute segments in full. In full is key here, because compressed instructions are impossible to seek backwards on, so for changes to happen I will need to find the first execute page, and then build from there.

At any rate, it is also possible to forego the faster instruction dispatch while I am building support for the Supervisor extension, which will greatly aid sanity.

I'm pretty happy with the emulator these days as it is still fairly thin, and hardly uses any memory to run programs. It is also running Go programs, with exception to the HTTP client example. I don't know what's keeping it from working, but I suppose I will eventually figure it out!

Nice work!

How did you debug it? Did you run it against the 'official' RISC-V models Spike [1] or Sail [2]?

[1] https://github.com/riscv-software-src/riscv-isa-sim

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

There is a doom emulation demo here now: https://github.com/fwsGonzo/libriscv/tree/master/emulator/do...

You will need to add the shareware doom1.wad yourself. :)

Mr Bellard did that too: https://bellard.org