Date: Mon, 22 Dec 1997 02:23:33 -0800 (PST) From: Jason Evans <jasone@canonware.com> To: "Christopher R. Bowman" <crb@ChrisBowman.com> Cc: Greg Lehey <grog@lemis.com>, Ric Flinn <rmf@radiks.net>, freebsd-sparc@FreeBSD.ORG Subject: Re: Register windowing Message-ID: <Pine.BSF.3.96.971221223614.367T-100000@mozart.canonware.com> In-Reply-To: <Pine.BSF.3.96.971221222215.257A-100000@quark.ChrisBowman.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 21 Dec 1997, Christopher R. Bowman wrote: > I haven't had a chance to wade through my Sparc V9 book, but on page xvii > it does say "we've accomplished this by making register windows more > flexible than they were in earlier SPARC processors, allowing the kernel > to provide a separate register bank to each running process. Thus, the > processor can perform a context switch with essentially no overhead ..." Well, after another 4+ hours of trying to extract the (extremely scattered) info on register windowing from the SPARC V9 Manual, I think I've mostly figured it out. It turns out that a separate spill/fill trap handler can be installed for each of the windows. This means that whenever we trap into the spill handler(s) we can tell which address space the window that needs spilled belongs to. The windows are essentially arranged in a circular buffer. Every window's ins overlap with one of its neighbors's outs, and vice versa. This creates the constraint that there must always be a one window gap both at the top and bottom of each process's set of windows (if there's only one process using the windows, this degenerates to a one window gap). Note also that we can never have valid windows for more than 4 address spaces (processes) at a time, given 8 windows. This means that if we want to create another window, we may cause a spill trap for an entirely different process's window. This is fine. What gets a bit more ugly though is if we incur a fill trap (i.e. we need to load the pertinent part of a stack frame from memory) then we no longer have any windows that belong to our process. In this case we use the window we've just vacated to load the stack frame into. This works fine, but we will only ever be able to restore one stack frame at a time. This seems reasonable to me, since we're trying to be lazy, and there are no apparent benefits to being otherwise. Using such a scheme, we need some auxiliary registers to keep track of: 1) Process id for each set of windows. 2) Top window for each set. 3) Something else I can't remember right now. Well, it turns out that we've got 8 unused registers in each gap, so we could probably use these for this info without a problem. We have to create clean windows anyway when giving a process a new window, so I don't think this will add much overhead, other than possibly changing CWP (current window pointer) twice to get at the registers. (If using these registers doesn't work out, there are other reasonable options for where to store the info.) We need to keep all of this state consistent, so when we switch processes, we not only need to determine what window to start with (check if we've already got valid windows for the new process); we also need to write info on the previous process's window state. This shines to be cheap though. I hope the scheme I've outlined is clear (it's getting late). I can't think of any reason to use another scheme at the moment, since this one seems to achieve maximum laziness with no additional penalty over other possible schemes. Comments? Jason P.S. One issue that may come up is the difference between V8 and V9 architectures. V9 allows nested traps, but I don't think V8 does, which requires much more care while in supervisor mode. This could directly affect window management. P.P.S. The most applicable sections of the V9 Manual to this are: 5.1.1.[2,3] 5.2.10*, 6.3.6*, and various parts of Appendix H. Jason Evans Email: [jasone@canonware.com] Home phone: [(650) 856-8204] Work phone: [(408) 774-8007] Quote: ["Invention is 1% inspiration, 99% perspiration" - Thomas Edison]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971221223614.367T-100000>