From owner-freebsd-sparc Sun Dec 21 00:15:18 1997 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA16879 for sparc-outgoing; Sun, 21 Dec 1997 00:15:18 -0800 (PST) (envelope-from owner-freebsd-sparc@FreeBSD.ORG) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA16873 for ; Sun, 21 Dec 1997 00:15:08 -0800 (PST) (envelope-from grog@lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id SAA00945; Sun, 21 Dec 1997 18:44:51 +1030 (CST) (envelope-from grog) Message-ID: <19971221184451.62453@lemis.com> Date: Sun, 21 Dec 1997 18:44:51 +1030 From: Greg Lehey To: Jason Evans Cc: Ric Flinn , freebsd-sparc@FreeBSD.ORG Subject: Re: Register windowing References: <34988B26.7F0C8B1B@radiks.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: ; from Jason Evans on Sat, Dec 20, 1997 at 10:54:11PM -0800 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Dec 20, 1997 at 10:54:11PM -0800, Jason Evans wrote: > 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): > > (etc) > > The main issue I can see here is how to decide how many register windows > should be saved or restored when a trap occurs. > > (etc) I think this sums up the issues pretty nicely. I suppose the only point to be made is that the number of windows in the register file varies greatly from one processor to another. Considering the interest in older processors, the code should be flexible enough to potentially be able to choose different strategies dependent on the processor. Greg From owner-freebsd-sparc Sun Dec 21 00:19:01 1997 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA17084 for sparc-outgoing; Sun, 21 Dec 1997 00:19:01 -0800 (PST) (envelope-from owner-freebsd-sparc@FreeBSD.ORG) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA17053 for ; Sun, 21 Dec 1997 00:18:28 -0800 (PST) (envelope-from grog@lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id SAA00966; Sun, 21 Dec 1997 18:48:11 +1030 (CST) (envelope-from grog) Message-ID: <19971221184811.36599@lemis.com> Date: Sun, 21 Dec 1997 18:48:11 +1030 From: Greg Lehey To: Jason Evans Cc: "Robert S. Sciuk" , Oliver Fromme , freebsd-sparc@FreeBSD.ORG Subject: Re: Data types (was: Re: FAQ FreeBSD-Sparc [frequent posting]) References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: ; from Jason Evans on Sat, Dec 20, 1997 at 11:40:55PM -0800 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Dec 20, 1997 at 11:40:55PM -0800, Jason Evans wrote: > > As for the UltraSPARC, I've been having a hard time finding info on the > efficiency of 32 vs 64 bit integer operations. This is of course an > issue, but I think that industry standards should take precedence over the > particulars of the UltraSPARC in this decision, simply because FreeBSD > could be an oddball otherwise. > > ... > > I've read through these web pages, as well as following the discussion > that ensued here. My feeling is that we should go with LP-64 (char --> 8, > short --> 16, int --> 32, long --> 64, pointer --> 64). This seems to me > the most useful from a programming perspective, and it also appears to be > the up and coming standard way of doing things. Like I said before, we > wouldn't be throwing away functionality by choosing this. This sounds like a good a priori approach, though it will cause problems where people assume sizeof (int) == sizeof (void *). But surely you should be able to find somebody under the Sun umbrella who can tell you what Solaris is planning to do for the UltraSPARC. I suppose this would apply to the question of register saving too. Greg From owner-freebsd-sparc Sun Dec 21 01:01:19 1997 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA18799 for sparc-outgoing; Sun, 21 Dec 1997 01:01:19 -0800 (PST) (envelope-from owner-freebsd-sparc@FreeBSD.ORG) Received: from mozart.canonware.com (canonware.com [206.184.206.112]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA18795 for ; Sun, 21 Dec 1997 01:01:12 -0800 (PST) (envelope-from jasone@canonware.com) Received: from localhost (jasone@localhost) by mozart.canonware.com (8.8.7/8.8.7) with SMTP id BAA00862; Sun, 21 Dec 1997 01:00:25 -0800 (PST) (envelope-from jasone@canonware.com) X-Authentication-Warning: mozart.canonware.com: jasone owned process doing -bs Date: Sun, 21 Dec 1997 01:00:25 -0800 (PST) From: Jason Evans To: Greg Lehey cc: Ric Flinn , freebsd-sparc@FreeBSD.ORG Subject: Re: Register windowing In-Reply-To: <19971221184451.62453@lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 21 Dec 1997, Greg Lehey wrote: > I think this sums up the issues pretty nicely. I suppose the only > point to be made is that the number of windows in the register file > varies greatly from one processor to another. Considering the > interest in older processors, the code should be flexible enough to > potentially be able to choose different strategies dependent on the > processor. Some definitions gleaned from manuals (used in this context): register window (or simply window) - An individual group of 24 registers representing the state of a stack frame, as saved when preparing for a function call. register file - The full set of integer registers available to user code. I can't find a term for a group of more than one register window. Is there one? You refer to the register file, but I think you're actually referring to this. The manuals refer to NWINDOWS as being a constant defined by each implementation, but that doesn't work very well for discussions. The sun4u processor has 8 register windows. Anyone know what the sun4m, sun4c, etc. has? If we use a simple solution such as trying to keep half of the windows full, the code won't need to be changed for each processor other than a few constants, but still, it would be good to know for future reference. Jason 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] From owner-freebsd-sparc Sun Dec 21 11:57:08 1997 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA21639 for sparc-outgoing; Sun, 21 Dec 1997 11:57:08 -0800 (PST) (envelope-from owner-freebsd-sparc@FreeBSD.ORG) Received: from radiks.net (root@sr.radiks.net [205.138.126.6]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA21613 for ; Sun, 21 Dec 1997 11:56:55 -0800 (PST) (envelope-from rmf@radiks.net) Received: from radiks.net (rmf@dmn120.radiks.net [208.154.148.142]) by radiks.net (8.8.8/8.8.8) with ESMTP id NAA09175; Sun, 21 Dec 1997 13:46:57 -0600 (CST) Message-ID: <349D746C.85A2D84F@radiks.net> Date: Sun, 21 Dec 1997 19:56:28 +0000 From: Ric Flinn X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) MIME-Version: 1.0 To: Jason Evans CC: freebsd-sparc@FreeBSD.ORG Subject: Re: Register windowing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org There are other ways for an OS to deal with register windows; consider the following: Instead of different register windows being used for function calls, have different windows available for different OS functions, such as interrupts and system calls. This way, when an interrupt occurs, you don't save the user program's registers, but just switch to a differnent (non-adjacent) window, which reduces a bit of overhead. Same with system calls, just switch to the kernel's register window. Now, I'm not saying that this is a better way, but that it may be one to consider, and may be easier to implement. Wouldn't the compiler have to be aware of windowing if user programs used them for nested function calls? Jason Evans wrote: > The sun4u processor has 8 register windows. Anyone know what the sun4m, > sun4c, etc. has? If we use a simple solution such as trying to keep half > of the windows full, the code won't need to be changed for each processor > other than a few constants, but still, it would be good to know for future > reference. I believe most of the newer processors have (at least) 8 (even the embedded SparcLite chip has 8), but I know some older machines 7, maybe some have fewer. Ric Flinn rmf@radiks.net From owner-freebsd-sparc Sun Dec 21 15:42:07 1997 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA06434 for sparc-outgoing; Sun, 21 Dec 1997 15:42:07 -0800 (PST) (envelope-from owner-freebsd-sparc@FreeBSD.ORG) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA06416 for ; Sun, 21 Dec 1997 15:41:46 -0800 (PST) (envelope-from grog@lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id KAA03067; Mon, 22 Dec 1997 10:11:13 +1030 (CST) (envelope-from grog) Message-ID: <19971222101113.50010@lemis.com> Date: Mon, 22 Dec 1997 10:11:13 +1030 From: Greg Lehey To: Ric Flinn Cc: Jason Evans , freebsd-sparc@FreeBSD.ORG Subject: Re: Register windowing References: <349D746C.85A2D84F@radiks.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <349D746C.85A2D84F@radiks.net>; from Ric Flinn on Sun, Dec 21, 1997 at 07:56:28PM +0000 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Dec 21, 1997 at 07:56:28PM +0000, Ric Flinn wrote: > There are other ways for an OS to deal with register windows; consider > the following: Instead of different register windows being used for > function calls, have different windows available for different OS > functions, such as interrupts and system calls. This way, when an > interrupt occurs, you don't save the user program's registers, but just > switch to a differnent (non-adjacent) window, which reduces a bit of > overhead. Same with system calls, just switch to the kernel's register > window. I think you're misunderstanding the Sparc hardware. The Sparc has a register file (we'll discuss the terminology when I find my Sparc books, which are still in the shed since moving house) which is addressed something like a stack. At any time, 24 registers are addressable, organized as 8 input, 8 local, and 8 output registers. These registers are called the register window. Each function call moves the pointer on by 16 registers, so the output registers of the calling function become the input registers of the called function. Jason went into more detail about this in an earlier posting. There is no question of using the register file for anything but local data storage in an individual program. Greg From owner-freebsd-sparc Sun Dec 21 17:03:59 1997 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA12598 for sparc-outgoing; Sun, 21 Dec 1997 17:03:59 -0800 (PST) (envelope-from owner-freebsd-sparc@FreeBSD.ORG) Received: from cynic.portal.ca (root@cynic.portal.ca [204.174.36.7]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA12588 for ; Sun, 21 Dec 1997 17:03:50 -0800 (PST) (envelope-from cjs@portal.ca) Received: from localhost ([[UNIX: localhost]]) by cynic.portal.ca (8.8.5/8.8.5) with SMTP id RAA14013; Sun, 21 Dec 1997 17:03:04 -0800 (PST) X-Authentication-Warning: cynic.portal.ca: cjs owned process doing -bs Date: Sun, 21 Dec 1997 17:03:04 -0800 (PST) From: Curt Sampson To: Greg Lehey cc: Jason Evans , "Robert S. Sciuk" , Oliver Fromme , freebsd-sparc@FreeBSD.ORG Subject: Re: Data types (was: Re: FAQ FreeBSD-Sparc [frequent posting]) In-Reply-To: <19971221184811.36599@lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 21 Dec 1997, Greg Lehey wrote: > > My feeling is that we should go with LP-64... Yes, this is what we use on NetBSD/alpha. > This sounds like a good a priori approach, though it will cause > problems where people assume sizeof (int) == sizeof (void *). You bet. You get used to fixing those after a while. Just like you get used to fixing alignment problems. :-) cjs Curt Sampson cjs@portal.ca Info at http://www.portal.ca/ Internet Portal Services, Inc. Through infinite mist, software reverberates Vancouver, BC (604) 257-9400 In code possess'd of invisible folly. From owner-freebsd-sparc Sun Dec 21 18:21:08 1997 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA17243 for sparc-outgoing; Sun, 21 Dec 1997 18:21:08 -0800 (PST) (envelope-from owner-freebsd-sparc@FreeBSD.ORG) Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id SAA17234 for ; Sun, 21 Dec 1997 18:20:54 -0800 (PST) (envelope-from softweyr@xmission.com) Received: from xmission.com [199.104.124.49] by mail.xmission.com with esmtp (Exim 1.73 #4) id 0xjxU9-0005kY-00; Sun, 21 Dec 1997 19:20:49 -0700 Message-ID: <349DD007.C0745CA9@xmission.com> Date: Sun, 21 Dec 1997 19:27:19 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: Jason Evans CC: Greg Lehey , Ric Flinn , freebsd-sparc@FreeBSD.ORG Subject: Re: Register windowing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jason Evans wrote: > > On Sun, 21 Dec 1997, Greg Lehey wrote: > > I think this sums up the issues pretty nicely. I suppose the only > > point to be made is that the number of windows in the register file > > varies greatly from one processor to another. Considering the > > interest in older processors, the code should be flexible enough to > > potentially be able to choose different strategies dependent on the > > processor. Not so much as you'd think. Most implementations have either 7 or 8 windows in the register file, because that is the "sweet spot" for performance. Sun did extensive studies of their existing 68K code when designing the SPARC architecture, and decided that most existing programs would arrive in steady states where they would stay for long periods of time needed a window size of 5, 6, or 7. The processors that have 8 windows in the register file are essentially adding one for performance. I'm not sure how many windows are typically saved and restored on over/ underflow, but I think it is typically one, to avoid large unexpected latencies. > Some definitions gleaned from manuals (used in this context): > > register window (or simply window) - An individual group of 24 registers > representing the state of a stack frame, as saved when preparing for a > function call. > > register file - The full set of integer registers available to user code. > > I can't find a term for a group of more than one register window. Is > there one? You refer to the register file, but I think you're actually > referring to this. The manuals refer to NWINDOWS as being a constant > defined by each implementation, but that doesn't work very well for > discussions. More than one are referred to as "windows." ;^) > The sun4u processor has 8 register windows. Anyone know what the sun4m, > sun4c, etc. has? If we use a simple solution such as trying to keep half > of the windows full, the code won't need to be changed for each processor > other than a few constants, but still, it would be good to know for future > reference. The SPARClite, and several other processors like it (like the TEMIC SPARClet) have 7. I think most SPARC v7 processors share this size; this would include the sun4 and sun4c machines. By the way, I have a good line on some really cheap ($50) Sun 4/110s, still running SunOS 4.1.1. Anyone wanna help do a sun4-nothing (arch = sun4) port of this? ;^) C'mon, 16Mhz SPARCs are great! -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com From owner-freebsd-sparc Sun Dec 21 18:28:55 1997 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA17745 for sparc-outgoing; Sun, 21 Dec 1997 18:28:55 -0800 (PST) (envelope-from owner-freebsd-sparc@FreeBSD.ORG) Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id SAA17736 for ; Sun, 21 Dec 1997 18:28:41 -0800 (PST) (envelope-from softweyr@xmission.com) Received: from xmission.com [199.104.124.49] by mail.xmission.com with esmtp (Exim 1.73 #4) id 0xjxbi-0006Nl-00; Sun, 21 Dec 1997 19:28:39 -0700 Message-ID: <349DD1D8.8C56047C@xmission.com> Date: Sun, 21 Dec 1997 19:35:04 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: Greg Lehey CC: Ric Flinn , Jason Evans , freebsd-sparc@FreeBSD.ORG Subject: Re: Register windowing References: <349D746C.85A2D84F@radiks.net> <19971222101113.50010@lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ric Flinn wrote: % There are other ways for an OS to deal with register windows; consider % the following: Instead of different register windows being used for % function calls, have different windows available for different OS % functions, such as interrupts and system calls. This way, when an % interrupt occurs, you don't save the user program's registers, but just % switch to a differnent (non-adjacent) window, which reduces a bit of % overhead. Same with system calls, just switch to the kernel's register % window. Greg Lehey replied: > I think you're misunderstanding the Sparc hardware. The Sparc has a > register file (we'll discuss the terminology when I find my Sparc > books, which are still in the shed since moving house) which is > addressed something like a stack. At any time, 24 registers are > addressable, organized as 8 input, 8 local, and 8 output registers. > These registers are called the register window. Each function call > moves the pointer on by 16 registers, so the output registers of the > calling function become the input registers of the called function. > Jason went into more detail about this in an earlier posting. There > is no question of using the register file for anything but local data > storage in an individual program. Actually, you can setup GCC to do what Ric suggests, it is sometimes done in embedded systems to keep the task switch latency down. The windows don't necessarily work the way you expect, due to the overlapping of the in/out registers, but they become a fast inter-process communications channel, for up to NWINDOWS-1 processes. Typically, window 0 is reserved for the OS core. You'd be astonished how bad your performance gets on most SPARC architectures when you try this. One important thing to keep in mind when designing using RISC architectures is the setup of the memory system. Think of it as a giant pipeline flowing into the processor -- anything flowing outward sets up eddies that you cannot begin to visualize. This is the reason for the large chip-local caches and the large register files on RISC chips. Trying to change the SPARC into a traditional stack-based architecture is a sure recipe for sluggish code. (I tried this one with my port of uC/OS to the SPARClite. Context switch times were fantastic, only about 20 instructions to switch, but the overall performance was so terrible I re-recompiled the entire library and went back to register windows. Now if I could just get the context switch to work entirely reliably... ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com From owner-freebsd-sparc Sun Dec 21 18:48:08 1997 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA19146 for sparc-outgoing; Sun, 21 Dec 1997 18:48:08 -0800 (PST) (envelope-from owner-freebsd-sparc@FreeBSD.ORG) Received: from radiks.net (root@sr.radiks.net [205.138.126.6]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA18790 for ; Sun, 21 Dec 1997 18:43:00 -0800 (PST) (envelope-from rmf@radiks.net) Received: from radiks.net (rmf@dmn124.radiks.net [208.154.148.146]) by radiks.net (8.8.8/8.8.8) with ESMTP id UAA18474; Sun, 21 Dec 1997 20:32:58 -0600 (CST) Message-ID: <349DD393.42FEC19C@radiks.net> Date: Mon, 22 Dec 1997 02:42:27 +0000 From: Ric Flinn X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-STABLE i386) MIME-Version: 1.0 To: Greg Lehey CC: Jason Evans , freebsd-sparc@FreeBSD.ORG Subject: Re: Register windowing References: <349D746C.85A2D84F@radiks.net> <19971222101113.50010@lemis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greg Lehey wrote: > I think you're misunderstanding the Sparc hardware. The Sparc has a > register file (we'll discuss the terminology when I find my Sparc > books, which are still in the shed since moving house) which is > addressed something like a stack. At any time, 24 registers are > addressable, organized as 8 input, 8 local, and 8 output registers. > These registers are called the register window. So far so good, you're terminoligy matches what I remember... > Each function call > moves the pointer on by 16 registers, so the output registers of the > calling function become the input registers of the called function. > Jason went into more detail about this in an earlier posting. I was under the impression this was left up to the implementation. The only experience I have with this processor was dealing with an embedded OS, which was designed similarly to the method I described (only more efficienly than my example, I wasn't directly involved with the OS at that level and can't really remember the details). If I recall this made the compiler easy to port to the sparc architecture because the prolog/epilog code was much simpler (since no register window switch for a function call), and the OS could change the current window freely as needed. > There > is no question of using the register file for anything but local data > storage in an individual program. Ok, that makes sense. Like I said, for the embedded os this wasn't the obvious choice, most likely due to porting time constrains above performance issues, but I can understand that it would be here. Doesn't this mean that the os must keep track of which windows need saved during a context switch (or possibly just save the whole file)? Ric Flinn rmf@radiks.net From owner-freebsd-sparc Sun Dec 21 19:30:40 1997 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA21554 for sparc-outgoing; Sun, 21 Dec 1997 19:30:40 -0800 (PST) (envelope-from owner-freebsd-sparc@FreeBSD.ORG) Received: from quark.ChrisBowman.com (crb.mnsinc.com [206.239.213.225]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA21547 for ; Sun, 21 Dec 1997 19:30:33 -0800 (PST) (envelope-from crb@ChrisBowman.com) Received: from localhost (crb@localhost) by quark.ChrisBowman.com (8.8.8/8.8.7) with SMTP id WAA00428; Sun, 21 Dec 1997 22:30:37 -0500 (EST) (envelope-from crb@ChrisBowman.com) X-Authentication-Warning: quark.ChrisBowman.com: crb owned process doing -bs Date: Sun, 21 Dec 1997 22:30:37 -0500 (EST) From: "Christopher R. Bowman" To: Greg Lehey cc: Ric Flinn , Jason Evans , freebsd-sparc@FreeBSD.ORG Subject: Re: Register windowing In-Reply-To: <19971222101113.50010@lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 22 Dec 1997, Greg Lehey wrote: >On Sun, Dec 21, 1997 at 07:56:28PM +0000, Ric Flinn wrote: >> There are other ways for an OS to deal with register windows; consider >> the following: Instead of different register windows being used for >> function calls, have different windows available for different OS >> functions, such as interrupts and system calls. This way, when an >> interrupt occurs, you don't save the user program's registers, but just >> switch to a differnent (non-adjacent) window, which reduces a bit of >> overhead. Same with system calls, just switch to the kernel's register >> window. > >I think you're misunderstanding the Sparc hardware. The Sparc has a >register file (we'll discuss the terminology when I find my Sparc >books, which are still in the shed since moving house) which is >addressed something like a stack. At any time, 24 registers are >addressable, organized as 8 input, 8 local, and 8 output registers. >These registers are called the register window. Each function call >moves the pointer on by 16 registers, so the output registers of the >calling function become the input registers of the called function. >Jason went into more detail about this in an earlier posting. There >is no question of using the register file for anything but local data >storage in an individual program. > >Greg 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 ..." and "We've also added eight new registers called 'alternate globals,' so the trap handler has a fresh register set to use immediately upon entry..." Which doesn't really refute what Greg says, but is interesting. --------- Christopher R. Bowman crb@ChrisBowman.com My home page From owner-freebsd-sparc Mon Dec 22 02:24:37 1997 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA14508 for sparc-outgoing; Mon, 22 Dec 1997 02:24:37 -0800 (PST) (envelope-from owner-freebsd-sparc@FreeBSD.ORG) Received: from mozart.canonware.com (canonware.com [206.184.206.112]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA14498 for ; Mon, 22 Dec 1997 02:24:27 -0800 (PST) (envelope-from jasone@canonware.com) Received: from localhost (jasone@localhost) by mozart.canonware.com (8.8.7/8.8.7) with SMTP id CAA04512; Mon, 22 Dec 1997 02:23:34 -0800 (PST) (envelope-from jasone@canonware.com) X-Authentication-Warning: mozart.canonware.com: jasone owned process doing -bs Date: Mon, 22 Dec 1997 02:23:33 -0800 (PST) From: Jason Evans Reply-To: Jason Evans To: "Christopher R. Bowman" cc: Greg Lehey , Ric Flinn , freebsd-sparc@FreeBSD.ORG Subject: Re: Register windowing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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] From owner-freebsd-sparc Mon Dec 22 11:25:59 1997 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA18465 for sparc-outgoing; Mon, 22 Dec 1997 11:25:59 -0800 (PST) (envelope-from owner-freebsd-sparc@FreeBSD.ORG) Received: from quark.ChrisBowman.com (crb.mnsinc.com [206.239.213.225]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA18016 for ; Mon, 22 Dec 1997 11:20:38 -0800 (PST) (envelope-from crb@ChrisBowman.com) Received: from localhost (crb@localhost) by quark.ChrisBowman.com (8.8.8/8.8.7) with SMTP id OAA01696; Mon, 22 Dec 1997 14:23:03 -0500 (EST) (envelope-from crb@ChrisBowman.com) X-Authentication-Warning: quark.ChrisBowman.com: crb owned process doing -bs Date: Mon, 22 Dec 1997 14:23:02 -0500 (EST) From: "Christopher R. Bowman" To: Jason Evans cc: Greg Lehey , Ric Flinn , freebsd-sparc@FreeBSD.ORG Subject: Re: Register windowing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 22 Dec 1997, Jason Evans wrote: >[ lot of stuff I haven't had time to digest delete ] > >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. This may become that place that we really need to decide how much support for older sun architecures we really want to build in from the start. Presumably, even if Jason only does a port to the Ultra architecture, we will have generalized support for sun machines including older stuff like the ss 4's, 5's and 10's and stuff like the ipc, ipx and the like (I can't really remember but I guess this means sun4c and sum4m) But if we take advantage of the nested traps, which BTW sounds like it will make things much cleaner/easier, then it may make supporting these older machines much harder. Whereas if we had spent a little time at the start thinking about these issues we might be in better shape. >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] > > > --------- Christopher R. Bowman crb@ChrisBowman.com My home page