-
Notifications
You must be signed in to change notification settings - Fork 147
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
Status of FEATURE_FASTCONTEXTS in cappuccino #158
Comments
Hi @zeldin sorry I missed your message. I really struggle to get notifications to me from gihub. I will try to figure this out. We don't use fast context switches in any OS's right now, and traditionally context is saved to the stack to allow for a more general context switching mechanism. But I do think fast context switching would be an interesting experiment and implementation would be appreciated. I have not even looked into it as per what I stated before. The issue with fast context switching is we will always have an upper bound of how many concurrent contexts we can support. This may be good for a small RTOS but might be hard to implement with a general OS like Linux. Would you be interested in writing some test software too to help show the benefits vs storing context to the stack? What are you thinking as a use case? |
My use case is not an OS, not even an RTOS, but bare metal embedded. I don't want multiple processes or anything, just efficient (both in space, as I want to be able to run from BRAM only, and in execution time) processing of interrupts and exceptions. Currently I use What environmental requirements would you have on such test software? Is something which runs on a Nexys A7 board and outputs something on the debug UART ok? Or runnable in some Icarus setup? |
If the change is in the mor1kx core any platform you use would be fine as long as the software can be built in newlib. I use either Litex or mor1kx-generic to run software either via simulations or FPGA. |
Well, it would have to be built with |
That should be fine, the one thing that is needed from newlib are the board libraries to handle reading/writing the UART.
Though, this does remind me that we have some re-entrant code somewhere in newlib that uses shadow registers to temporarily store context. I could not find it on first glance. This might creep up later. Good luck. |
@stffrdhrn So, I wanted to try using your
Is this also a work in progress? |
@stffrdhrn Hm, actually, never mind, it looks like I misinterpreted the "Illegal Wishbone B3 cycle type" as a fatal error. It does run correctly. |
Thanks, yes that illegal wishbone cycle is something that is a bit misleading. Everything does look to work right as per the log. I'll look at the readme typos |
@stffrdhrn Working on the FASTCONTEXTS implementation, I found an inconsistency in the OpenRISC 1000 Section 6.3 says that CID is incremented on exception. But section 6.4.2 says that exceptions switch to the main context (CID=0). Either way works for me, but do you happen to know which way it's supposed to be? |
This is interesting, I looked into it there are two different things here. The SR[CID] 4-bits whick refer to the current context. Then there is the CXR 32-bit register which also had details of the context. The thing is the CXR register doesn't seem to be an spr and I don't know if our assembler even supports this name. But also this CXR is supposed to be used for manual context switching. It's not used when automatic fast switching is enabled. |
Yes, however automatic fast switching is supposed to write the previous value of |
Just wanted to add that I did make a test software. All of it, including main and exception stack, fits in 2 Kbyte of BRAM (the vector table at address 0x0000-0x1fff is pure combinatorial and not backed by BRAM or registers). But now I need to actually implement FCS for it to work properly (if you run it now there is some register contention between the tick timer handler and the main loop, giving incorrect output) and I can't do that without some clarity on which way CID is supposed to move on an exception when |
The cappuccino CPU has a parameter
FEATURE_FASTCONTEXTS
which is said to "Enable fast context switching of register sets". Setting this toENABLED
makesSR[CE]
writable, howeverSR[CE]
does not seem to actually do anything.SR[CID]
is not writable, and the top bits ofwb_rfd_adr_expand
,rfa_rdad
, andrfb_rdad
are all hard-coded to 0.Is
FEATURE_FASTCONTEXT
expected to be useful for anything now? Is there work planned in this area? Would you accept a PR which madeSR[CID]
writable,SR[CE]
increment it on exception, and used its bits to select the current GPR set?The text was updated successfully, but these errors were encountered: