-
Notifications
You must be signed in to change notification settings - Fork 218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exception handling issues #3
Comments
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. |
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.
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. |
That would be fantastic if the URET issue could be fixed. |
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. |
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
Section: 18.5
|
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? |
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. |
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. |
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. |
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. |
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. |
@phummel, I made a issue to track an M-mode feature. |
User-mode exception handling does not completely conform with the specification. It has several bugs.
The text was updated successfully, but these errors were encountered: