Date: Tue, 15 Aug 2006 10:52:48 -0400 From: John Baldwin <jhb@freebsd.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, David Xu <davidxu@freebsd.org>, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/amd64/amd64 support.S Message-ID: <200608151052.49421.jhb@freebsd.org> In-Reply-To: <20060815135517.GB41562@deviant.kiev.zoral.com.ua> References: <200608151245.k7FCjpJo077372@repoman.freebsd.org> <200608152134.46359.davidxu@freebsd.org> <20060815135517.GB41562@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <fusufault>: > > 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 <fusufault>: > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200608151052.49421.jhb>