From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/559 Path: news.gmane.org!not-for-mail From: Solar Designer Newsgroups: gmane.linux.lib.musl.general Subject: Re: tough choice on thread pointer initialization issue Date: Fri, 10 Feb 2012 14:42:52 +0400 Message-ID: <20120210104252.GA14485@openwall.com> References: <20120210025824.GA25414@brightrain.aerifal.cx> <20120210074002.GA13559@openwall.com> <20120210075818.GG146@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1328870588 25594 80.91.229.3 (10 Feb 2012 10:43:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 10 Feb 2012 10:43:08 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-560-gllmg-musl=m.gmane.org@lists.openwall.com Fri Feb 10 11:43:05 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1RvnwW-0002WG-Tw for gllmg-musl@plane.gmane.org; Fri, 10 Feb 2012 11:43:05 +0100 Original-Received: (qmail 5403 invoked by uid 550); 10 Feb 2012 10:43:01 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 5373 invoked from network); 10 Feb 2012 10:43:01 -0000 Content-Disposition: inline In-Reply-To: <20120210075818.GG146@brightrain.aerifal.cx> User-Agent: Mutt/1.4.2.3i Xref: news.gmane.org gmane.linux.lib.musl.general:559 Archived-At: On Fri, Feb 10, 2012 at 02:58:18AM -0500, Rich Felker wrote: > On Fri, Feb 10, 2012 at 11:40:02AM +0400, Solar Designer wrote: > > approach 4: initialize the thread pointer register to zero at program > > startup. Then before its use, just check it for non-zero instead of > > checking a global flag. (I presume that you're doing the latter now, > > based on your description of the problem.) > > Well this is definitely feasible but it makes more arch-specific code, > since examining the thread register needs asm. But accessing it needs asm anyway, no? > I suspect "mov %gs,%ax" might be slow on some machines, too, It might be. On the other hand, segment registers are read (saved) on context switch, so this is not something CPU makers would disregard. I wouldn't be surprised if some CPU has faster push than mov, though. > since the segment registers > aren't intended to be read/written often. I just don't know enough to > know if it's a good approach; if you really think it's potentially the > best, perhaps you could provide more info. "Potentially" is the keyword here, but anyway I just did some testing on a Core 2'ish CPU (E5420), and the instruction is very fast. I put 1000 instances of: movl %ss,%eax testl %eax,%eax jz 0 one after another, and this runs in just 1 cycle per the three instructions above (so 1000 cycles for the 1000 instances total). Of course, there are data dependencies here, so there's probably a bypass involved and the instructions are grouped differently, like: Cycle N: testl %eax,%eax; jz 0; movl %ss,%eax Cycle N+1: testl %eax,%eax; jz 0; movl %ss,%eax with a bypass between testl and jz. (I am just guessing, though.) In actual code (where you won't have repeats like this), you might want to insert some instructions between the mov and the test (if you can). I also tested 1000 instances of: movl %gs,%eax and: movw %gs,%ax and: movw %gs,%ax testw %ax,%ax All of these execute in 1000 cycles total as well. With "w" forms of the instructions there are extra prefixes, so I think these should better be avoided, even though there's no slowdown from them on this CPU. Alexander