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 TLSregister. 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.