This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: thread-ready ABIs
- From: "Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>
- To: "Kevin D. Kissell" <kevink at mips dot com>
- Cc: "H . J . Lu" <hjl at lucon dot org>, Machida Hiroyuki <machida at sm dot sony dot co dot jp>, drepper at redhat dot com, GNU C Library <libc-alpha at sources dot redhat dot com>, linux-mips at oss dot sgi dot com
- Date: Mon, 21 Jan 2002 14:56:21 +0100 (MET)
- Subject: Re: thread-ready ABIs
- Organization: Technical University of Gdansk
On Mon, 21 Jan 2002, Kevin D. Kissell wrote:
> If anything, assuming that k0 or k1 are sane in
> compiler-generated code is more of a violation
> of the ABI than imposing an optional use of s7.
> Sony's use in libraries is somewhat less intrusive.
Hmm, it's a glibc/kernel internal implementation detail. I don't think
this is an ABI violation, as from a program's point of view k0/k1 are
still "undefined -- do not use".
> 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.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +