rars
rars copied to clipboard
TheThirdOne
Support A extension
I previously thought no one needed rv64 support, but I was wrong about that. Similarly I don't see the need for atomics as RARS doesn't have threading. However, the A extension is part of the the G set, so it seems possible that someone does want it implemented.
I am going to leave this open and if you want this implemented please share your use case here. Until someone presents a use case, this will remain unimplemented.
I think having atomic instruction support would be good, at the very least load reserved and store conditional. We use this tool when teaching RISC-V assembly and would like for students to run basic synchronous programs in RISC-V. On my local fork, I've got basic support for the load reserved and store conditional instructions. How much work do you think it would take for RARS to support multi-threading?
I don't understand how RARS would be much help teaching synchronization primitives; it would only be able to show uncontested accesses.
It would probably take about a month of full time work to make multi-threading work.
I'm currently looking at implementing multi-threading as well which is why I'm asking.
Since you are looking at implementing multi-threading here are some of the issues that would be time sinks:
- Registers currently use static variables so in order to have multiple independent harts you would need to remove that.
- It might be possible to swap out register banks between execution of different harts, but that would be hacky.
- Memory is currently completely atomic. It is locked before any accesses.
- Like with registers, there is only one simulator that uses static variables.
- The assumption that there is only one thread of execution is used in lots of places.
I think that some kind of Tool to simulate memory accesses without a full RISC-V hart would get better results per unit of effort. It may also be worth it to make multi-threading as Tool so less core RARS needs to be changed; copying Register and Simulator code into a Tool would sidestep 2 of the issues above.