4 ms·

It looks like it's the season for hobby RISC-V emulators, because I've also been working on one. https://github.com/michaelmelanson/riscy https://github.com/mi

It looks like it's the season for hobby RISC-V emulators, because I've also been working on one. https://github.com/michaelmelanson/riscy https://github.com/michaelmelanson/riscy The tricky part here comes when you have to run non-trivial programs. Mine currently passes the basic test suites, but it still fails in the C runtime startup when executing programs compiled with GCC. My next step is to do co-simulation with another emulator in order to find out where their execution states diverge.

thethirdone 6y ago
> Mine currently passes the basic test suites The tests in riscv-tests are not complete enough to indicate strong compliance. I have found several bugs in my implementation that were not caught by them. > but it still fails in the C runtime startup when executing programs compiled with GCC The biggest issue I have seen with running C programs is that people don't have the system calls that C runs on startup. In a log from rv8, you need brk, uname, readlinkat, and mprotect. So without those you shouldn't be able to get a program into user code unless you make a custom entry point. Source: I am the maintainer of RARS (https://github.com/TheThirdOne/rars https://github.com/TheThirdOne/rars)
- a-priori 6y ago
  > The tests in riscv-tests are not complete enough to indicate strong compliance. I have found several bugs in my implementation that were not caught by them. I've noticed that, yes. They got me pretty far, but there's something I'm doing wrong and I haven't been able to find what. That's why the next thing I'm going to try is co-simulation. > The biggest issue I have seen with running C programs is that people don't have the system calls that C runs on startup. In a log from rv8, you need brk, uname, readlinkat, and mprotect. So without those you shouldn't be able to get a program into user code unless you make a custom entry point. Yes, that hasn't been a problem so far. I've written minimal implementations of a few (so far: fstat, brk, exit) as I've gone along. https://github.com/michaelmelanson/riscy/blob/master/emulator/src/subsystem/posix.rs https://github.com/michaelmelanson/riscy/blob/master/emulato...

thethirdone 6y ago

> Mine currently passes the basic test suites The tests in riscv-tests are not complete enough to indicate strong compliance. I have found several bugs in my implementation that were not caught by them. > but it still fails in the C runtime startup when executing programs compiled with GCC The biggest issue I have seen with running C programs is that people don't have the system calls that C runs on startup. In a log from rv8, you need brk, uname, readlinkat, and mprotect. So without those you shouldn't be able to get a program into user code unless you make a custom entry point. Source: I am the maintainer of RARS (https://github.com/TheThirdOne/rars https://github.com/TheThirdOne/rars)

a-priori 6y ago
> The tests in riscv-tests are not complete enough to indicate strong compliance. I have found several bugs in my implementation that were not caught by them. I've noticed that, yes. They got me pretty far, but there's something I'm doing wrong and I haven't been able to find what. That's why the next thing I'm going to try is co-simulation. > The biggest issue I have seen with running C programs is that people don't have the system calls that C runs on startup. In a log from rv8, you need brk, uname, readlinkat, and mprotect. So without those you shouldn't be able to get a program into user code unless you make a custom entry point. Yes, that hasn't been a problem so far. I've written minimal implementations of a few (so far: fstat, brk, exit) as I've gone along. https://github.com/michaelmelanson/riscy/blob/master/emulator/src/subsystem/posix.rs https://github.com/michaelmelanson/riscy/blob/master/emulato...