Subject: TLS register

From: Guido Guenther <[email-masked]>
Date: Mon, 31 May 2004 20:05:24 -0300

Hi,
Now that gcc 3.4 has incompatible ABI changes (on o32 mostly affecting
mipsel) I've been discussing with Thiemo if I'd be the right point to
take this ABI change as a possibility to additionally reserve a TLS
register. 
He suggested $24 (t8) another discussed possibility would be $27 (k1)
which is already abused by the PS/2 folks for ll/sc emulation.
Another possibility would be to reserve such a register only in the
n32/n64 ABIs and let o32 stay without __thread and TLS forever.
Any feedback welcome.
 -- Guido

---

From: "Steven J. Hill" <[email-masked]>
Date: Mon, 31 May 2004 22:17:41 -0500

> n32/n64 ABIs and let o32 stay without __thread and TLS forever.
I vote for $24 (t8). LL/SC emulation is an issue and I believe some of
the exception vectors, if not all of them indirectly depend on k1. It
would take a lot of work (and testing) to rewrite the exceptions to not
utilize k1 and it would probably be a nasty performance hit in many
cases. I agree with "Screw o32" and let's move forward.

-Steve

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 1 Jun 2004 14:15:20 +0200

> n32/n64 ABIs and let o32 stay without __thread and TLS forever.

Sigh, we'e been through this really often enough.  Reserving a register
comes at a price so my approach was to implement a fast path in the
exception code.  I've benchmarked that long time ago; it had less than
half the overhead than normal syscall and such a function would be subject
to normal code optimizations so calls should be few only.  Alpha already
does something similar using their PAL code.

  Ralf

---

From: "Kevin D. Kissell" <[email-masked]>
Date: Tue, 1 Jun 2004 14:44:08 +0200

> does something similar using their PAL code.

The overhead realtive to a normal syscall is much less interesting
to measure than the overhead relative to having the pointer already
in a register - after all, half of a whole lot of instructions is still a whole
lot of instructions.

As some, but perhaps not all of you know, MIPS is working on
multithreaded extensions to the instruction set architecture and
the hardware, which include the ability to create and destroy
parallel threads of executioon without OS intervention in the
"expected" case (and yes, I have thought about how Linux 
could support this, but I'm not gonna go into that here).
In such a framework, it would not be acceptable to do a
system call to get a TLS value.

I don't yet have an opinion as to whether we need to retrofit
things so that user-level multithreading is compatible with o32,
but I would comment that if we go for a TLS register, k1 may 
not be a very good option. The LL/SC emulation trick with k1 
works by virtue of k1 being *destroyed* by exceptions - it doesn't 
change its status as a register reserved for kernel use.

            Regards,

            Kevin K.

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 1 Jun 2004 16:28:37 +0200 (CEST)

> > > n32/n64 ABIs and let o32 stay without __thread and TLS forever.

 For Linux the n32/n64 ABIs can be considered being in the initial stage
of deployment, so backwards compatibility is a non-issue.  Whatever is
found to be the best solution may be accepted.  So the problem of defining
a TLS pointer exists for the o32 ABI only and given the existence of
MIPS32 ISA and its implementations ignoring the issue won't only affect
ancient (but still alive) hardware.

> > does something similar using their PAL code.

 It seems a reasonable balance, IMO.

> in a register - after all, half of a whole lot of instructions is still a whole

 The interesting factor is how much software really needs threading.  
AFAIK, the majority does not -- I can count threaded software I know of 
(but not necessarily use) using fingers of one hand.  That does not mean 
there are no niches that make use of that approach extensively -- they 
could see a benefit, but why to penalize the rest?

> system call to get a TLS value.

 Well, this is exactly a good counter-argument for having a TLS pointer in
a gp register.  I someone needs the fastest threading possible, then let
them use the right hardware (with the threading ASE) or accept the
inefficiency of hardware that predates the concept of threading.

> change its status as a register reserved for kernel use.

 Actually the trick has never found its way into the mainline, and perhaps
it's best to keep it outside as messing with the k registers is inherently
fragile.  Of course, this applies to a possibility to use one of them for
the TLS, too. ;-)

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: David Daney <[email-masked]>
Date: Tue, 01 Jun 2004 12:21:56 -0700

>ancient (but still alive) hardware.

There are MIPS32 ISA processors that are used in embedded devices that 
are far from "ancient" as some are only starting to enter the market, 
and are still in production.

For these types of devices it is not so important to maintain backwards 
compatibility with legacy tool chains and/or binary library code.  A new 
ABI very similar to o32 but with a TLS pointer in a register (perhaps 
"o32-tls") might be useful.
.
.
.

>could see a benefit, but why to penalize the rest?
Almost any non-trivial program written in java could benefit from faster 
TLS.  The java support in GCC-3.4 now allows us to write useful programs 
for MIPS in java.

David Daney.