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.
