Actions

icon Post
text/html Subscribe
text/html Unsubscribe

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

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


  • To: "'Daniel Jacobowitz'" <dan@xxxxxxxxxxxxxxxx>, "'Nigel Stephens'" <nigel@xxxxxxxx>
  • Subject: RE: [mips-tls] A couple of potential changes to the MIPS TLS ABI
  • From: "Michael Uhler" <uhler@xxxxxxxx>
  • Date: Wed, 9 Feb 2005 12:41:49 -0800

> From this discussion I am still inclined to stay with rdhwr.  
> 30-60 cycles is not very long.

The problem that I'm having with this email thread is that I no longer
understand what problem is being solved.  You're getting push-back from the
MIPS folks, including me, about a solution that uses emulation of an
instruction which is unlikely to be actually implemented in hardware any
time soon, if ever.  It sounds like the ARM people are having the same
heartburn for the same reason.  There appears to be no appreciable
benchmarking that suggests that a trap-and-emulate approach will be fine, or
not so fine in terms of performance of the solution.

If the problem we're trying to solve is to get NPTL to work on MIPS, period
the end, then we can stop the email thread now.  That certainly seems to be
the path we're taking as of now.

If we're trying to find a solution to the problem such that MIPS isn't at a
competitive disadvantage, perhaps we should start looking for such a
solution, rather than rejecting suggestions because of the changes to the
current software implementation.

So can you please crisply state what problem we're trying to solve here, and
the bounds on an acceptable solution from your point of view.  I'm really
confused.

/gmu

---
Michael Uhler, Chief Technology Officer
MIPS Technologies, Inc.   Email: uhler@xxxxxxxx
1225 Charleston Road      Voice:  (650)567-5025   FAX:   (650)567-5225
Mountain View, CA 94043   Mobile: (650)868-6870   Admin: (650)567-5085