Date: Wed, 24 Oct 2012 09:24:02 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Peter Grehan <grehan@FreeBSD.org> Cc: svn-src-projects@FreeBSD.org, src-committers@FreeBSD.org, Jilles Tjoelker <jilles@stack.nl> Subject: Re: svn commit: r241744 - projects/bhyve/usr.sbin/bhyve Message-ID: <50878982.8090604@FreeBSD.org> In-Reply-To: <50877F67.1040409@freebsd.org> References: <201210191811.q9JIBIQu049356@svn.freebsd.org> <20121021121006.GA96141@stack.nl> <5085D433.4020101@freebsd.org> <20121023095549.GA27951@stack.nl> <5086C976.9060705@freebsd.org> <5086D040.1090307@FreeBSD.org> <50877F67.1040409@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 24/10/2012 08:40 Peter Grehan said the following: > Hi Andriy, > >> If this code emulates something like mov into %eax on AMDD64, then it should >> clear >> upper 32-bits of %rax. Which I think your original code already did, but in a >> less obvious way than Jilles suggested above. >> But I could be very well confused... > > The 0x88/0x89 forms of the MOV instruction don't touch bytes outside of the > operand size. They do (if I am not confusing the opcodes) in the 32-bit destination register case. This is called implicit zero extension. This is not documented in the MOV instruction section (at least in the AMD manual), but it is documented in appendix B.1 'General Rules for 64-Bit Mode': Zero-Extension of 32-Bit Results: Operations on 32-bit operands in 64-bit mode zero-extend the high 32 bits of 64-bit GPR destination registers. 8-bit/16-bit operations still have the historic semantics. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50878982.8090604>