Exception handling issues

[TheThirdOne]

User-mode exception handling does not completely conform with the specification. It has several bugs.

• The interrupt controller cannot handle being stepped backwards. This could be as simple as defining a new back stepper action and threading it in. However, its not quite clear what the behavior should be after back-stepping; what should happen to external devices that are communicating with it?
• WFI doesn't quite work correctly; while waiting, if the step button or the run button is pressed you can get two instances running at the same time. This can also happen if you click too fast, but it is very noticeable with WFI. A temporary solution is to just make WFI a nop as that conforms to the specification. Alternatively, making stepping interrupt the wait would also work.
• URET doesn't reset all of the state it should. Specifically, it does not follow "Execution of URET will place the uepc, ucause, and utval back into initial state."
• And likely more.

[zacharyselk]

Hi there, I was wondering if there has been any work on this bug. Also I was curious if there was any workarounds for the URET problem of resetting the states.

[TheThirdOne]

I haven't worked on fixing this issue specifically, but I have started work which should make the first part easier.

External devices cannot (in general) be stepped backwards so the correct behavior for the 1st issue is still up in the air.

WFI is hard to make interruptable by hitting run / step for technical reasons, but if you want a compliant implementation, replacing it with a nop is still possible.

The URET issue should be pretty easily solvable. It's probably pretty doable as a Pull Request if someone wants it fixed.

Something preventing me from really taking action to improve exception handling is that I haven't read the most recent privileged specification. My spec knowledge is based on the preliminary specs from 2 years ago. If you are doing something with exception handling, I could take some time to try to improve it.

Also I was curious if there was any workarounds for the URET problem of resetting the states.

I don't think there would be any workarounds from assembly. I think there could be easy additions to RARS which would allow URET to work as you would need to in any given program.

[zacharyselk]

That would be fantastic if the URET issue could be fixed.
I am currently working on restructuring a systems course to use RISC-V instead of MIPS and I am hoping to have students use this simulator to do assignments involving timing and keyboard interrupts. Do you know of any other issues with the interrupt handling that might cause problems or result undefined behaviour when implementing basic traps?

[TheThirdOne]

I was never sure of how to treat time in RARS with regards to backstepping and pausing. As a result, RDTIME is not implemented and any timer interrupt code won't be able to use it. I'm also not sure if RARS supports a way of doing timer interrupts; I may have left that as something a tool would handle.

I don't know of any other issue you may encounter, but I'll take a look into interrupts and try to fix any inconsistencies.

[TheThirdOne]

I took a look into the N extension and the privileged spec. It seems that since 2017, the spec of user level interrupts has changed. Currently it does not seem that there is any requirement to reset uepc, ucause, and utvalue as they aren't valid outside handling an exception. Its possible that for interrupts fired while handling an interrupt that it may be required, but that is a case not clearly covered by the spec.

And RARS is compliant with the current specification with regards to the N extension as far as I can tell.

The relevant quotes from the RISC-V ISM v2.2:

Section: 18.2

The URET instructions is used to return from traps in U-mode, and URET copies UPIE into UIE,then sets UPIE.

Section: 18.5

In particular, uepc, ucause, and utvalue only valid during execution of a trap handler.

[zacharyselk]

That is great to hear!

Also I have started working on implementing timer interrupts and I thought I should check to see if that is something that you are currently working on?

[TheThirdOne]

I'm not currently on implementing timer interrupts.

I checked and found that DigitalLabSim has a timer interrupt, but its probably not sufficient for your needs.

Is there a specific reason why your fork is implemented as part of RARS core rather than as a tool? From what I've seen, it should be implementable as a tool.

[zacharyselk]

I was hoping to implement the entire timing hart which seemed to be more of a core aspect (especially because it has dedicated CSRs). But it can be moved to being a tool without too much trouble. The architecture is pretty messy at the moment just trying to get everything working properly then I plan on refactoring and relocating most of the code to more appropriate areas.

[phummel]

When looking into redoing the interrupt system, I wonder how difficult it would be to add machine interrupts (mie, mstatus, mepc, etc). Adding those registers to the CSR is simple enough, I have those patches that I could create a pull request for, but the changes to the simulator are less straight forward. Currently my fork changes all the uxxx to mxxx in the simulator for my use.

[TheThirdOne]

Currently RARS is set up as a U-mode simulator and as such doesn't have access to M-Mode registers. Supporting an M-mode only setting should not be very hard, but would be non-trivial. Supporting switching from U mode and M mode at runtime would be quite hard.

I presume that m-mode CSRs would be useful because there is example code (somewhere not in this repo) for handling interrupts in m-mode or because you want compatibility with some hardware/software. Please let me know a little bit more about your use case.

[phummel]

A simple setting or option for the simulator to use either U-mode or M-mode would cover our use case completely.

We build a single-cycle RISC-V in our course and use RARS to assemble RISC-V code into a hex dump for loading and simulating the behavior of RISC-V assembly code. The hardware we implement uses only M-mode registers.

Currently, I have a separate fork that works for us now. If I get time, I can work on this.

[TheThirdOne]

@phummel, I made a issue to track an M-mode feature.