1. How mature/stable is it? I know that's a bit difficult a question to answer for the creator. But I'll have > 200 students, and if the tools I give
them are buggy I'll have to deal with a complaint avalanche. (MARS
is very stable.)
2. I want to build a test suite for automatic evaluation of student
code generators, such that student RISC-V code is automatically run in the simulator
and the result of the evaluation is compared with the expected result (I supply the latter). The whole thing needs to be scriped, since my test cases are numerous, and I don't want to cut/paste student code into a window. Is there any
facility that allows me to use your simulator as a linkable library,
rather than calling it from the command line? This would be
extremely convenient. (MARS can be run from the command line and can be scripted into a test suite but it's a bit inconvenient.)
As far as I am aware it is very stable. There were three slight bugs that I fixed after they were brought to my attention. #6, #7, #8 in the issue tracker .
There are some known bugs that are hard to fix, but I doubt any student would run into them as they all have to do with CSRs iirc or interrupts.
I try to be pretty responsive about issues when they are brought up; if it were holding up a class, I would spend some time to fix the issue. And its possible that a motivated student would be able to fix the problem themselves.
> 2. I want to build a test suite ... Is there any facility that allows me to use your simulator as a linkable library, rather than calling it from the command line? ...
IIRC the command line wasn't significantly changed so your existing command line script should work. As for a linkable library, depending on what you are looking for that should be possible. It is possible that there is some global state which makes it hard to reset properly.
When you say "linkable library" are you looking for a .jar with a clear api?
Is the inconvenience just about not wanting to script in bash? Or is it about JVM startup time?
I'll look into what it would take to make a easily configurable launch class.
> When you say "linkable library" are you looking for a .jar with a clear api?
Yes, a .jar with a clear API would be ideal. Maybe a method with a signature like so:
run :: String -> RISC_V_State
- Error or successful-completion
- Content of registers (in fact content of one register should be
fine as long as that register can be used as an accumulator).
Clearly all this is available internally already, so it'd just be a
matter of creating a suitable API.
I am aware of the global state issue. I would be happy to launch a new
JVM for each test, although that is very slow (10000 tests * 200
students = 2,000,000 JVM starts). If there was a suitable "reset"
method in the exposed API that would be even better.
If you have a github account, feel free to make an issue. If not I'll make one after I get some sleep; I've been awake for far too long.
When I was working on this full-time, there wasn't a good way to learn in a comprehensive manner. Some instructions were incredibly unclear even looking at the specification.
If you were familiar with other RISC assembly, I think making a simple project using RARS (or other simulator) would be a pretty good way to get a baseline understanding.
Compiling C applications to risc-v assembly can also be helpful.
If the parent also isn't familiar with how CPUs and caching works and wants to learn that along with RISC-V assembly it is probably a good bet.
Assembly tutorials: https://github.com/MattPD/cpplinks/blob/master/assembly.risc...
This list has three books, including the one recommended elsewhere in this thread. There is a much cheaper introduction as well.
I'll take a look at the RISC-V specification. Thanks!
Having spent a fair amount of time reading and referring to the specification, I definitely would not recommend it for someone who isn't familiar with assembly.
It is free though, so giving it a shot might be worth it.
I'm old - and binary is how one would bootstrap a new computer, and assembly was an hll.
Disclaimer: I'm no RISC-V expert and I didn't look at RARS for very long, so these might be stupid questions.
Currently there isn't a whole lot in the README; part of the goal of this post is to find questions that people would like answered in it.
> Is an object file used for this or does the assembler just use the labels in the open files?
The compilation is done entirely in memory and I don't recall any of the classes being analogous to a traditional object file. One of the things I would like to implement in the future is linking with ELF object files, and loading, executing and exporting ELF executables. However, that is a relatively big addition and I don't fully understand the ELF format.
> Is there a list of the system calls you implement?
I don't believe there is an easily accessible, static list. But RARS generates a list of available system calls accessible from the help menu.
The classes for the system calls are all in this directory . If its a supported system calls, its in that directory.
> Did you follow an example or standard or did you just make up some system calls?
In the translation from MARS, I kept a lot of the MARS/SPIM specific syscalls. However, to have at least a semblance of Linux (and with any other existing simulators) compatibility I implemented a few of the easy Linux system calls and remapped some of the MARS system call numbers to the ones used in Spike .
> Disclaimer: I'm no RISC-V expert and I didn't look at RARS for very long, so these might be stupid questions.
No worries. I can't expect you to be an expert and these are very reasonable questions. Thanks for asking.
> RARS was built on MARS 4.5
How much did you have to change to support RISC-V? Is this easy to extend this work to add support for other RISC architectures?
It took a fair amount; if you are particularly motivated, the git log is an accurate description of the work I did.
As for making this work for other RISC architectures, if they have fixed size instructions, its should be relatively simple (given this project as a template for what to change). I would expect it to take maybe 80 hours or so to do something on the scale of RISC-V. But that estimate is likely not very accurate.
After considering a bunch of other education focused environments, I chose MARS because it was easy to extend and did pretty much exactly what I wanted from a UI perspective.
Generally I would say the main differences are: the whole RISC vs CISC argument, how future extensions work and how complicated decoding/encoding instructions is.
I'm not going to go into RISC vs CISC as that has been constantly fought over and I am not qualified to have a substantiated position.
The extension system for RISC-V is the biggest area where I think RISC-V excels. There is a very simple base instruction set which has things like loads/stores, addition, and branches. Then more complicated instructions such as multiplication, floating point, atomics, etc are all extensions which have a well defined structure and there is dedicated room for more standard extensions and custom ones.
The technical advantage of this is that really cheap CPUs can support a tiny fraction of what big ones do, but still fit into the same mold as the big ones. Any custom instructions for a specific product can just be a custom instruction. Additionally, if an extension becomes useless in the future, just don't include it in future chips.
If this has caught your attention, check out the specification .
IIRC, the decoding and encoding of RISC-V is dramatically simpler than x86 and ARM as it has only a normal 32 instruction format, a compressed 16 bit one and a large one (I think 128 bit). Importantly the non-default sizes are optional. MIPS has a simpler format, but takes slightly more silicon to decode (because its more human readable).
I don't know any good references off the top of my head though, but I suspect searching for risc-v on HN is probably a good bet to find discussion of pros and cons.
The upcoming V (vector processing) extension also chooses an approach that (while far from novel) hasn't seen much use recently, but will probably work better than the usual sort of SIMD for most use cases.
It's worth mentioning the "privileged" architecture as well, as it benefits hugely from being a from-scratch design; it's a lot simpler than its equivalent in most other architectures, and it will probably support things like virtualization in a rather straightforward way.
If you hit a roadblock that makes you stop wanting to learn, let me know in an issue. I am looking to improve RARS and add some documentation around it to help ease people in.