From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CgWgK-0006ZQ-OI for qemu-devel@nongnu.org; Mon, 20 Dec 2004 18:11:13 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CgWgF-0006Wj-Ps for qemu-devel@nongnu.org; Mon, 20 Dec 2004 18:11:10 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CgWgE-0006V1-Dl for qemu-devel@nongnu.org; Mon, 20 Dec 2004 18:11:06 -0500 Received: from [200.83.1.24] (helo=mx01.vtr.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CgWSd-0005DB-3E for qemu-devel@nongnu.org; Mon, 20 Dec 2004 17:57:03 -0500 Received: from hudson.vtr.net (200.83.1.22) by mx01.vtr.net (7.1.026) id 41932EDB0129C3BE for qemu-devel@nongnu.org; Mon, 20 Dec 2004 19:56:55 -0300 Received: from fw.aplik (200.104.148.28) by hudson.vtr.net (7.0.027) (authenticated as aplik@vtr.net) id 4178B9F10155FF0D for qemu-devel@nongnu.org; Mon, 20 Dec 2004 19:56:55 -0300 Received: from pcdaniel.aplik (daniel@[192.168.0.4]) by fw.aplik (8.11.6/8.11.6) with SMTP id iBKMutm04004 for ; Mon, 20 Dec 2004 19:56:55 -0300 Date: Mon, 20 Dec 2004 19:56:54 -0300 From: Daniel Serpell Subject: Re: [Qemu-devel] Re: [PATCH] CONFIG_MMU_MAP powerpc host support Message-ID: <20041220225654.GA32678@aplik.cl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi! El Mon, Dec 20, 2004 at 11:12:31PM +0100, Magnus Damm escribio: > [...] > But if we could combine the most popular > guest instructions into one micro operation (which is not so micro > anymore) then the compiler could rearrange things to fully take > advantage of the host cpu. > > It all boils down to some table-based generic guest opcode matching > code that does a longest prefix match and supports masking of > bitfields... > > I think it would be very interesting to collect opcode statistics for > certain guest operating systems. Or maybe someone already has done > that? > I have done that, it's not so difficult. I added a fixed static two dimensional table (int ins_usage[MAX_INS][MAX_INS]), an then a global variable "int last_ins". Also, I moddified the "ops*.h" and "op.c" files, adding at the beggining: "ins_usage[last_ins][THIS_INS]++; last_inst=THIS_INS;", with THIS_INS initialized to some unique constant. The problem is, I then realized that I measured the instructions usage but not the time spent in each instruction, and the instructions doing memory-access where spending almost all the emulated time. So, I presumed that accelerating memory-access were a better project. If you are interested, I could send the patches. Daniel.