Show HN: IDE for Learning RISC-V

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.)

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.

This list has three books, including the one recommended elsewhere in this thread. There is a much cheaper introduction as well.

Assembly tutorials: https://github.com/MattPD/cpplinks/blob/master/assembly.risc...

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 [0]. 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 [1].

> 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.

[0]: https://github.com/TheThirdOne/rars/tree/master/rars/riscv/s... [1]: https://github.com/riscv/riscv-isa-sim

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.

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.

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 [0].

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.

[0]: https://content.riscv.org/wp-content/uploads/2017/05/riscv-s...

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.