[mips-tls] A couple of potential changes to the MIPS TLS ABI

[Daniel Jacobowitz]

On Tue, Feb 01, 2005 at 02:10:50AM -0800, Michael Uhler wrote:
> The one area that I'm concerned about is the use of rdhwr to return the
> pointer.  There are several reasons why I'm not sure this is the right thing
> to do:

I'm getting a lot of conflicting feedback about this.

> - rdhwr is a MIPS32/64 Release 2 instruction.  No existing MIPS I-IV
> implementation has this instruction and probably never will.  Even existing
> MIPS3264 Release 2 implementations don't have the internal register to hold
> the data.  This means that it will be years before any hardware will support
> the feature, and that support depends on an architecture decision (see next
> item)

Compare this to a syscall.  There is no existing implementation which
will implement the syscall efficiently, and _never_ will be.

> - We have some concerns at the architecture level about using rdhwr for this
> purpose rather than using a GPR under the umbrella of an ABI re-work that
> some of you are involved in.

This objection is way too vague for me to respond to.  Also, using
rdhwr does not prevent future use of a GPR, in an ABI that doesn't
exist yet.  Nice thing about read-only state; you can keep it in
multiple places easily.

> - Some preliminary work at MIPS suggests that a tuned handler for syscall is
> faster than one for handling rdhwr at the reserved instruction handler.
> This means that we're betting on having actual hardware implementations of
> rdhwr out there in sufficient volume to make up for the fact that we're
> penalizing everybody else by using an RI trap hander vs. a syscall trap
> handler.

So is this one.  Can you be more specific?  The only substantial
difference in overhead that I am familiar with is the additional
register save/restores; note that this is a substantial _advantage_ for
userland which would otherwise have to save and restore additional
registers.  Keeping the save/restores in the kernel is a win for code
size and complexity.

> To me, all of these suggest that we may want to use syscall rather than
> rdhwr to get the pointer, at least until we can decide whether to dedicate a
> GPR for this purpose.

In any case, I am putting Ralf on the hot seat here.  I'm going to do
whatever he likes, anyway, since it's no good to me if the kernel
doesn't support it :-)

-- 
Daniel Jacobowitz