site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Sun, 11 Sep 2005, Matt Watson wrote: On Sep 11, 2005, at 10:35 AM, Gary Byers wrote: As I thought I explained in my message, I'm concerned about perfomance. There's a difference between "having a dedicated register point to TLS" and "having an API for fast access to TLS." An example of the latter is described in: <http://people.redhat.com/drepper/tls.pdf> Yes, I know. I can't access that thread-local storage directly (without the overhead of a function call), because the contents of r13/%gs are opaque. It's certainly a step forward to not require a trap to access thread-local storage. It would be a further step forward to not require a function call. I was trying to describe the issue. I honestly thought that I did so, If you still don't understand the point that I'm trying to make, I'd be willing to try again. matt. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... The concerns that I have aren't based on the belief that the pthread library functions are somehow grossly inefficient If not performance, then what are your concerns, exactly? Darwin/x86 already uses %gs internally as the selector for TLS, just like Linux. The 64-bit PowerPC ABI reserves r13 for TLS. Since the 32-bit PowerPC Mac OS X ABI does not provide a register dedicated to TLS, Darwin/ppc uses a user readable SPRG on platforms which support it (i.e. G5), and an optimized kernel trap on platforms which don't. Perhaps if you stated your complaint more succinctly, without trying to design the solution first, it would be more evident how you would like the implementation to behave. This email sent to site_archiver@lists.apple.com