On Wed, Apr 16, 2014 at 1:16 PM, Stefan Wallentowitz <[email protected]> wrote: > Hi all, > > I currently port the GNU newlib toolchain for my multicore extensions. I > again face a particular problem with the lack of shadow registers during > exceptions. For the moment I have an acceptable workaround by using > ISR0-ISR7, but I think this might be worth discussing (or may have be > discussed before) as it is a rather generic issue. > > Let me shortly summarize the issue: When an exception occurs, the > register file can not be used as long as the state prior to the > exception was saved. It is therefore necessary to store the current > context (or at least parts of it): > > * The GNU toolchain currently puts stuff on the current stack what does > fail with virtual memory. > * Linux stores the exception context somewhere between 0x0 and 0x100 > > Now that I have several processor cores running, I can of course not use > this method on a shared memory. Any kind of offset calculation already > requires a register. So what we did previously was adding a scratch pad > 256 Byte memory on the data path. Nevertheless the core should be > self-contained and it would be good to a nice solution :) > > I personally see three options (ascending endorsement from my side): > * Use a private scratch pad memory (similar to QMEM in or1200) in the LSU > * Use ISR0-ISR7. I am not sure what the precise idea of > "implementation-specific" is here, specific to the SW, OS or HW? At the > moment I can freely use them, but if the software uses them too, it is > again part of the context.. > * Make some GPRs shadow registers, e.g. 1-8, and access them with an > mfspr during an exception as EGPR1-EGPR8 > * Define extra exception registers that are reserved to be used during > the first steps of an exception (similar to how I use ISR0-7 now) > > What are your opinions? >
As I mentioned in another thread, I've grown less hostile than I first was towards this. And now I've came into the position where I believe we really need it ;) Long story short, I've been looking into what would be needed to make the reg stashing in the Linux kernel per-cpu, and I had an idea that I would be able to use the globally reserved register r10. The reason I believed this was that the only usage within the kernel was for the thread_info pointer, and that only needs to be reserved *within* the kernel. All was going well until Christian pointed out that r10 is now used by the TLS code. So, the end result is that in Linux, we now have 0 scratch regs to use. I've been giving this some *further* more thought, and I believe what might be the best solution, both from a "keep the arch spec changes down" and an implementation point of view, is to allow implementations to use the GPR SPR address space to add another set of GPRs, but without being forced to implement all of the "heavy" context-switch stuff. What do you think? Stefan _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
