On Aug 26, 2014, at 6:39 PM, Peter Gavin <[email protected]> wrote: > On Tue, Aug 26, 2014 at 9:00 PM, Matt Thomas <[email protected]> wrote: > I'd be happy that if fast context switching isn't implemented that an extra > partial set (4 is enough, 8 is better) of GPR SPRs would be made available. > > Finishing the fast context switching/shadow register stuff is probably the > best way to go with this, IMO.
I agree, mostly. But it seems incomplete. > The problem with using SPRs for temporary data is that accessing them is > slow, because the SPR number must be calculated and decoded in order to > determine which SPR is being accessed. My implementation actually flushes > the pipeline on mtspr instructions, and my guess is that other pipelines are > similar, because the mtspr can change important pipeline state in a way that > is not predictable. (I could have avoided the flush in some cases, but I > didn't think the extra logic was worth it.) And the register being written > to by mtspr is probably determined too late to easily bypass the result to > earlier pipe stages (unless you have a really deep pipeline). So, depending > on pipeline depth and architecture, an mtspr instruction can effectively take > several cycles to execute. The result is that it probably won't be any > faster than just going through main memory, assuming a reasonable cache hit > rate. Without SPRGs, not trashing registers on exception becomes more difficult. Because r0 is not fixed as 0, the very first thing the exception handler must do is l.xor r0, r0, r0 to make sure r0 is zero. Or I suppose you can use r0 as an early temporary and then set it to 0 later. Or you can reserve two registers for exclusive kernel use like MIPS does. It just gets nasty. > BTW I think I remember finding some problems with fast context switching as > defined in the spec. It's been a while since I looked at that so I can't > recall what those problems are now. And IIRC, there are *no* implementations > that support it, not even or1ksim. _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
