From owner-freebsd-arch  Sun Aug 18 17:40:15 2002
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 4581337B400
	for <arch@FreeBSD.ORG>; Sun, 18 Aug 2002 17:40:09 -0700 (PDT)
Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38])
	by mx1.FreeBSD.org (Postfix) with ESMTP id DACFD43E6E
	for <arch@FreeBSD.ORG>; Sun, 18 Aug 2002 17:40:08 -0700 (PDT)
	(envelope-from julian@elischer.org)
Received: from InterJet.elischer.org ([12.232.206.8])
          by rwcrmhc51.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
          id <20020819004008.WVMZ1746.rwcrmhc51.attbi.com@InterJet.elischer.org>;
          Mon, 19 Aug 2002 00:40:08 +0000
Received: from localhost (localhost.elischer.org [127.0.0.1])
	by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA43374;
	Sun, 18 Aug 2002 17:34:40 -0700 (PDT)
Date: Sun, 18 Aug 2002 17:34:37 -0700 (PDT)
From: Julian Elischer <julian@elischer.org>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: Ian Dowse <iedowse@maths.tcd.ie>, Bruce Evans <bde@zeta.org.au>,
	arch@FreeBSD.ORG
Subject: Re: Solving the stack gap issue 
In-Reply-To: <Pine.BSF.4.21.0208181659440.42036-100000@InterJet.elischer.org>
Message-ID: <Pine.BSF.4.21.0208181733320.42036-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-arch.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-arch>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-arch>
X-Loop: FreeBSD.ORG

duh.....
restate the question..


On Sun, 18 Aug 2002, Julian Elischer wrote:

> 
> On Sun, 18 Aug 2002, Matthew Dillon wrote:
> >     I would consider this to be more expensive:
> > 
> > 	proc1()
> > 	{
> > 	    struct thread *td = curthread;
> > 	    ...
> > 	    proc2(td)
> > 	}
> > 
> > 	proc2(td)
> > 	{
> > 	    ...
> > 	}
> > 
> >     And this to be less expensive:
> > 
> > 	proc1()
> > 	{
> > 	    proc2();
> > 	}
> > 
> > 	proc2()
> > 	{
> > 	    struct thread *td = curthread;
> > 
> > 	    ... use td several times ...
> > 	}
> 
> yes but what about:
> 
> 
>        proc1()
>        {
>            struct thread *td = curthread;
>            ...
> 	   someotherfn(td)
>            proc2(td)
>        }
> 
>        proc2(td)  
>        {
>            ...
>            ... use td several times ...
>        }
> 
> vs 
>        proc1()
>        {
>            struct thread *td = curthread;
>            ...
>            someotherfn(td)
>            proc2(td)
>        }
> 
>        proc2(td)
>        { 
>            ...
>            ... use td several times ...
>        }
> 
> so that proc1 needs td anyhow..
> 
> > 
> >     At least for I386.  Ultimately I think this will be generally true on
> >     any architecture.  If a procedure uses 'curthread' multiple times loading
> >     it into a local at the top of the procedure should be a sufficient 
> >     optimization.  Passing td around to dozens or hundreds of procedures
> >     just for the sake of avoiding accessing 'curthread' is bad design.
> > 
> > 					-Matt
> > 					Matthew Dillon 
> > 					<dillon@backplane.com>
> > 
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-arch" in the body of the message
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message