Support A extension

[TheThirdOne]

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.

[giancarlopernudisegura]

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?

[TheThirdOne]

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.

[giancarlopernudisegura]

I'm currently looking at implementing multi-threading as well which is why I'm asking.

[TheThirdOne]

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.