[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: TLS register

Maciej W. Rozycki wrote:

On Tue, 1 Jun 2004, Kevin D. Kissell wrote:

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.

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.

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.

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?

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.

Reply to: