From owner-cvs-src@FreeBSD.ORG Tue Aug 15 15:09:11 2006 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C90716A50B; Tue, 15 Aug 2006 15:09:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62BA143E5E; Tue, 15 Aug 2006 15:08:09 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k7FF84WC028048; Tue, 15 Aug 2006 11:08:05 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Kostik Belousov Date: Tue, 15 Aug 2006 10:52:48 -0400 User-Agent: KMail/1.9.1 References: <200608151245.k7FCjpJo077372@repoman.freebsd.org> <200608152134.46359.davidxu@freebsd.org> <20060815135517.GB41562@deviant.kiev.zoral.com.ua> In-Reply-To: <20060815135517.GB41562@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608151052.49421.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 15 Aug 2006 11:08:05 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1663/Tue Aug 15 09:08:37 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: cvs-src@freebsd.org, src-committers@freebsd.org, David Xu , cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/amd64/amd64 support.S X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2006 15:09:11 -0000 On Tuesday 15 August 2006 09:55, Kostik Belousov wrote: > On Tue, Aug 15, 2006 at 09:34:46PM +0800, David Xu wrote: > > On Tuesday 15 August 2006 21:13, John Baldwin wrote: > > > On Tuesday 15 August 2006 08:45, David Xu wrote: > > > > davidxu 2006-08-15 12:45:51 UTC > > > > > > > > FreeBSD src repository > > > > > > > > Modified files: > > > > sys/amd64/amd64 support.S > > > > Log: > > > > Because fuword on AMD64 returns 64bit long integer -1 on fault, clear > > > > entire %rax to zero instead of only clearing %eax, otherwise it will > > > > leave garbage data in upper 32 bits. > > > > > > Are you sure that 'xorl %eax,%eax' doesn't actually clear all 64 bits? > > > This practice of just using xorl rather than xorq is all over the place in > > > the amd64 code, and I think I've even seen gcc generate it, so I'm guessing > > > that the xorl actually is a xorq. > > > > >From my understanding, they are different. > > > > before my change, generated binary code: > > > > 0000000000003ba0 : > > 3ba0: 65 48 8b 0c 25 20 00 mov %gs:0x20,%rcx > > 3ba7: 00 00 > > 3ba9: 31 c0 xor %eax,%eax > > 3bab: 48 89 81 a8 02 00 00 mov %rax,0x2a8(%rcx) > > 3bb2: 48 ff c8 dec %rax > > 3bb5: c3 retq > > 3bb6: 66 data16 > > 3bb7: 66 data16 > > 3bb8: 66 data16 > > > > ======================================= > > after this change: > > > > 0000000000003ba0 : > > 3ba0: 65 48 8b 0c 25 20 00 mov %gs:0x20,%rcx > > 3ba7: 00 00 > > 3ba9: 48 31 c0 xor %rax,%rax > > 3bac: 48 89 81 a8 02 00 00 mov %rax,0x2a8(%rcx) > > 3bb3: 48 ff c8 dec %rax > > 3bb6: c3 retq > > > > > > I have only checked fuword while I am working on userland mutex > > priority propagating, I have not checked suword and others yet. > > From the IA32 Software Developer Manual, 3.4.1.1: > > When in 64-bit mode, operand size determines the number of valid bits in > the destination general-purpose register: > > 64-bit operands generate a 64-bit result in the destination > general-purpose register. > > 32-bit operands generate a 32-bit result, zero-extended to a 64-bit > result in the destination general-purpose register. > > So, it seems that xorq %rax, %rax and xorl %eax, %eax will make the > same results, but in the different ways. And xorq requires REX prefix, > that shall make the decoding longer. Ok, thanks! David, can you revert your change? I had almost gone through earlier and fixed all the places that did this a while back until I realized that it must have been intentional. -- John Baldwin