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? >
Since this is Non-Linux specific, could you use r10 that is pinned down as the thread_info pointer in Linux. (we should really document this as our ABI and call it something in line with "reserverd for kernel/OS use"). Stefan _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
