From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IY0jy-0003TN-86 for qemu-devel@nongnu.org; Wed, 19 Sep 2007 10:41:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IY0jw-0003SA-AH for qemu-devel@nongnu.org; Wed, 19 Sep 2007 10:41:21 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IY0jw-0003S7-5F for qemu-devel@nongnu.org; Wed, 19 Sep 2007 10:41:20 -0400 Received: from bangui.magic.fr ([195.154.194.245]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IY0ju-00020K-Dt for qemu-devel@nongnu.org; Wed, 19 Sep 2007 10:41:19 -0400 Subject: Re: [Fwd: Re: [Qemu-devel] [PATCH] SVM support] From: Jocelyn Mayer In-Reply-To: <00FC6422-CB9E-4C8D-9B27-C77A072A1234@suse.de> References: <1190148856.14938.247.camel@rapid> <1190156750.14938.295.camel@rapid> <200709190028.52730.paul@codesourcery.com> <00FC6422-CB9E-4C8D-9B27-C77A072A1234@suse.de> Content-Type: text/plain Date: Wed, 19 Sep 2007 16:39:30 +0200 Message-Id: <1190212770.12194.16.camel@jma4.dev.netgem.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: l_indien@magic.fr, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: qemu-devel@nongnu.org, Paul Brook On Wed, 2007-09-19 at 12:56 +0200, Alexander Graf wrote: > On Sep 19, 2007, at 1:28 AM, Paul Brook wrote: > > >>>> Ok, I will try to shift the intercepts in an uint_64 flags variable > >>>> in the TB. > >> > >> OK, great. Having 64 bits may also help for additional (ie future...) > >> features in PowerPC 64 emulation. > > > > Maybe worth letting the target say whether it needs 32 or 64-bit > > flags. > > The flag lookup is likely to be on a hot path. > > > > Paul > > here comes the patch. The patch looks correct to me, I'm just wondering why a cast to 32 bits is needed in mips code ? I may be wrong, but it seems to me that TB flags are only used to be compared in tb_find_fast and tb_find_slow, which are not a very fast path (we come here when we cannot jump directly to the next tb and are not in the most time critical code) then we can afford adding a few asm instructions (I would say max 2 ?) to replace a 32 bits comparison with a 64 bits one. My feeling is that the performance loss here won't be sensible, but that may need to be proved.