From owner-freebsd-arch  Sun Aug 18 17:20:20 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 E84F237B400
	for <arch@FreeBSD.ORG>; Sun, 18 Aug 2002 17:20:11 -0700 (PDT)
Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 4541043E4A
	for <arch@FreeBSD.ORG>; Sun, 18 Aug 2002 17:20:11 -0700 (PDT)
	(envelope-from julian@elischer.org)
Received: from InterJet.elischer.org ([12.232.206.8])
          by sccrmhc02.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
          id <20020819002010.VVMB13899.sccrmhc02.attbi.com@InterJet.elischer.org>;
          Mon, 19 Aug 2002 00:20:10 +0000
Received: from localhost (localhost.elischer.org [127.0.0.1])
	by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA43307;
	Sun, 18 Aug 2002 17:05:03 -0700 (PDT)
Date: Sun, 18 Aug 2002 17:05:00 -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: <200208181933.g7IJXYC5072982@apollo.backplane.com>
Message-ID: <Pine.BSF.4.21.0208181659440.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


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()
       }

       proc2()
       { 
           struct thread *td = curthread;
           ...
           ... 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