Date: Tue, 15 Aug 2006 16:55:17 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: David Xu <davidxu@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, John Baldwin <jhb@freebsd.org> Subject: Re: cvs commit: src/sys/amd64/amd64 support.S Message-ID: <20060815135517.GB41562@deviant.kiev.zoral.com.ua> In-Reply-To: <200608152134.46359.davidxu@freebsd.org> References: <200608151245.k7FCjpJo077372@repoman.freebsd.org> <200608150913.52419.jhb@freebsd.org> <200608152134.46359.davidxu@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--JP+T4n/bALQSJXh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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, cle= ar > > > 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?= =20 > > 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 gues= sing > > that the xorl actually is a xorq. >=20 > >From my understanding, they are different. >=20 > before my change, generated binary code: >=20 > 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 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > after this change: >=20 > 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 >=20 >=20 > I have only checked fuword while I am working on userland mutex > priority propagating, I have not checked suword and others yet. =46rom 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. --JP+T4n/bALQSJXh8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE4dJFC3+MBN1Mb4gRAlUoAKDmt4xrO5EmGkp49S+MUnhYkbOKYwCfUBb8 qKGxk+VxNPQqPxmMurxaEZo= =7l+g -----END PGP SIGNATURE----- --JP+T4n/bALQSJXh8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060815135517.GB41562>