Date: Sun, 21 May 2000 16:44:50 -0600 From: Wes Peters <wes@softweyr.com> To: Arun Sharma <adsharma@sharmas.dhs.org> Cc: arch@FreeBSD.ORG Subject: Re: Sparc & api for asynchronous task execution (2) Message-ID: <392866E2.389A6935@softweyr.com> References: <200005182045.NAA21595@usr08.primenet.com> <3924DA18.392990EA@softweyr.com> <20000520104248.A2866@sharmas.dhs.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Arun Sharma wrote:
>
> On Fri, May 19, 2000 at 12:07:20AM -0600, Wes Peters wrote:
> > > > This makes going up and down when you don't overflow
> > > > very fast at the expense of when you add to the total depth.
> >
> > The register window sizes weren't picked willy-nilly. The SPARC default
> > size is 7 windows, chosen after months of analyzing every M68K SunOS
> > program they could get their hands, including compiled C, Pascal, LISP,
> > and Fortran programs.
>
> Times have changed. If you have looked at stack traces in Mozilla or
> Konqueror, they easily go 40 calls deep.
Even old SPARC software typically went 20 to 25 frames deep, that's not
the issue. The issue is how many frames are active during the normal
useful 75% - 85% of a program lifecycle, when it is actively accomplishing
work, as opposed to starting up or shutting down. I suspect this is
higher for C++/Java code than apocryphal C/Pascal/Fortran code, but I
doubt it is more than 1 or 2 higher than the original 7.
> The real problem with sparc register windows is flushing of the stack
> on every system call. Clever software tricks can avoid this on IA-64.
On every context switch, you mean. The fastest way to do this is to
put a LOT of registers on the chip, obviating the need to spill registers
unless you have a LOT of threads.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?392866E2.389A6935>