On Tue, May 13, 2014 at 8:47 AM, Wallentowitz, Stefan <[email protected]> wrote: >>On Mon, May 12, 2014 at 4:07 PM, Jonas Bonn <[email protected]> wrote: >>> i) scratch space really just comes down to one or two per-cpu >>> variables; we don't really need SPR's for this at all, but having some >>> freely usable SPR's allows us to stash some per-cpu variables there >>> instead of in memory > >>JFYI (but probably you know), MIPS has 2 of them (k0 and k1). These are part >>of the GPRs, though, which has the >disadvantage that you loose >>2 (out of 32) GPRs, but the advantage that you can use them in most >>instructions. > > Hi, > > isn't it, that those are shadowed? They are only visible during exceptions > and the original registers are only accessible with special instructions, I > think. > For OpenRISC that would mean something like having R1 and R2 that are > different during exceptions. Original R1 and R2 can then only accessed like: > l.mfspr r1, r0, SPR_GPR1 > The advantage of having R1 would be, that we already have the exception stack > at hand, which would be neat. >
No, they (k0 and k1) are not (AFAIK at least), they are completely regular GPRs, with the only exception that they are "reserved for kernel/OS" use. This was my intention with (the now discarded) r10 idea, to get a similar setup. 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. Stefan _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
