On Tue, May 13, 2014 at 9:09 AM, Stefan Kristiansson <[email protected]> wrote: > Anyway, if we go back to the SPR scratch reg discussion and reg shadowing, > I think a setup where we have to manually copy the registers into a > scratch space is preferable over them being automatically "shadowed". > The reasons are: > > 1) It makes the implementation more transparent to existing software > (i.e. behaviour on exception entry is not different if the scratch > regs are not used) > This could of course be solved with some mechanism where the shadowing > would be needed to be switched-on before it starts to work, but I > still think the manual option is better. > > 2) Implementation wise, the logic to add some writeable SPRs is a lot > more simple than if you will have to start fetching register values > out of the register file upon exception entry. >
...and after reading up a bit more on the definition of the "shadow registers" in the arch spec, I've came to realize that from a software point of view, all that is needed is in there. To sum it up: 1) The "Number of Shadow GPR Files" can be read from CPU Configuration Register (CPUCFGR) in the NSGF field (>0 means that there are shadow register files). 2) To enable automatic register shadowing, the CE (CID Enable) bit in the SR (Supervisor Reg) SPR should be set. So, a piece of software that is only interested in 1) (i.e. Linux in this case) is completely free to omit 2) and read/write the additional GPR file with the l.mfspr and l.mtspr instructions. The only thing that is a little bit unclear, is whether an OR1K implementation is allowed to only implement 1), but not 2). I think this is minor issue though, and could be settled with only a minor clarification (that it can be allowed) in the arch spec. Stefan _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
