linux-mips
[Top] [All Lists]

Re: thread-ready ABIs

To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Subject: Re: thread-ready ABIs
From: "H . J . Lu" <hjl@lucon.org>
Date: Mon, 21 Jan 2002 10:24:55 -0800
Cc: "Kevin D. Kissell" <kevink@mips.com>, Machida Hiroyuki <machida@sm.sony.co.jp>, drepper@redhat.com, GNU C Library <libc-alpha@sources.redhat.com>, linux-mips@oss.sgi.com
In-reply-to: <Pine.GSO.3.96.1020121144413.22392C-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Mon, Jan 21, 2002 at 02:56:21PM +0100
References: <003701c1a25f$8abfc120$0deca8c0@Ulysses> <Pine.GSO.3.96.1020121144413.22392C-100000@delta.ds2.pg.gda.pl>
Sender: owner-linux-mips@oss.sgi.com
User-agent: Mutt/1.2.5i
On Mon, Jan 21, 2002 at 02:56:21PM +0100, Maciej W. Rozycki wrote:
> 
> > It's a common technique to bind a static register
> > to a global variable.  Linking to libraries with no
> > knowledge of this variable breaks nothing, since
> > by the ABI, all use of "s" registers requires that
> > they be preserved and returned intact to the caller.
> > It seems to me to be quite straightforward to apply
> > this technique to the thread register.  The *only*
> > issue I see is that of performance, and it is by
> > no means clear how severe this would be.
> 
>  The k0/k1 approach is a performance hit as well.  Possibly a worse one,
> as you lose a few cycles unconditionally every exception, while having one
> static register less in the code can be dealt with by a compiler in a more
> flexible way.  
> 
> > In the compiled code that I have examined
> > for compiler efficiency in the past, it's pretty
> > rare that *all* static registers are actually used.
> 
>  Even with one register less there are still eight remaining, indeed.

If people believe it won't be a big problem, we can tell gcc not to use
$23, at least when compiling glibc.  The question is, should $23 be
fixed outside of glibc? Ulrich, should applciations have access to
thread register directly? If not, we may add a switch to tell gcc that
$23 is fixed and compile glibc with it.



H.J.

<Prev in Thread] Current Thread [Next in Thread>