Date: Sat, 20 Dec 1997 22:54:11 -0800 (PST) From: Jason Evans <jasone@canonware.com> To: Ric Flinn <rmf@radiks.net> Cc: freebsd-sparc@FreeBSD.ORG Subject: Re: Register windowing Message-ID: <Pine.BSF.3.96.971218020120.503D-100000@paladio> In-Reply-To: <34988B26.7F0C8B1B@radiks.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 18 Dec 1997, Ric Flinn wrote: > I just recenly joined this list, and I'm no expert in the Sparc > architecture or Sparc OS's, but I'm curious about how FreeBSD for the > sparc will handle register windowing. I know there are several ways an > OS can use register windowing, perhaps there are obvious advantages to > one method or another that I don't know about. Well, I don't think I can answer your question, so let me outline what I understand of register windowing so that we can start a discussion that can lead to the OS register windowing handler methods you refer to. Here are basic bits of info that I think are true (correct me if I'm wrong): A register window consists of the 24 non-global integer registers in the non-privileged register file. 8 of those registers are specified for passing arguments to nested functions (outs). 8 are specified for receiving the return values from function calls (ins). The other 8 are for local variables. (Stack pointers are included in these numbers.) Adjacent register windows overlap, in that if foo calls bar, foo's outs are the same as bar's ins. The CPU has room to buffer a certain number of register windows on chip without having to write them out to memory. So, the operating system gets involved when all of its register window buffers fill, and another register window is saved. This creates a register window overflow, or spill trap. The OS then has to save some number (>0) of register windows to the program stack. The inverse is when restoring a register window, it isn't already in a buffer, which causes a register window underflow, or fill trap. Now the OS has to restore some number of register windows from the stack into the CPU (>0). ---- The main issue I can see here is how to decide how many register windows should be saved or restored when a trap occurs. Say we've got a program doing deep recursion and we only save one window at a time when a spill trap occurs. We're going to end up trapping every time we recurse. On the other hand, say that we flush all of the windows when a spill trap occurs. But the program then returns with out calling any deeper nested functions. Now we've got a fill trap on our hands. So a policy of flushing and restoring the maximum number of windows on a trap can also be bad. If we took the approach of trying to keep the window register buffers half occupied, this would seem to be a nice middle ground, though certain applications (such as deeply recursive) would see much better performance if we took a different approach. The possibility of dynamic adjustment comes to mind, but it seems to me that it would be extremely difficult to implement useful statistical methods without spending so much time in analysis that we lose the benefits. Is this what you were getting at? I haven't read any particulars about how OSes handle these issues, and I'd love to hear about it. Jason P.S. Apologies to all of you for my "disappearance" over the last couple of days. I've been busy setting up my mail server, and felt it prudent to get the mail problems taken care of instead of sporadically responding to email. 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.971218020120.503D-100000>