From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DNMbv-0007Jo-LZ for qemu-devel@nongnu.org; Sun, 17 Apr 2005 23:07:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DNMbt-0007J6-Vn for qemu-devel@nongnu.org; Sun, 17 Apr 2005 23:07:43 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DNMZK-0006jw-U6 for qemu-devel@nongnu.org; Sun, 17 Apr 2005 23:05:03 -0400 Received: from [64.233.162.192] (helo=zproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DNMCG-00008y-1z for qemu-devel@nongnu.org; Sun, 17 Apr 2005 22:41:12 -0400 Received: by zproxy.gmail.com with SMTP id 8so311015nzo for ; Sun, 17 Apr 2005 19:39:44 -0700 (PDT) Message-ID: <2ad73a0504171939154235f5@mail.gmail.com> Date: Sun, 17 Apr 2005 23:39:44 -0300 From: =?ISO-8859-1?Q?Andr=E9_Braga?= Subject: Re: [Qemu-devel] Profiling Qemu for speed? In-Reply-To: <20050418013615.89123.qmail@web51604.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050418013615.89123.qmail@web51604.mail.yahoo.com> Reply-To: =?ISO-8859-1?Q?Andr=E9_Braga?= , 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 The problem with table lookups (I'm assuming you're talking about function pointer vectors) is that they *destroy* spatial locality of reference that you could otherwise attain by having series of if-then-else instructions and some clever instruction prefetching mechanism on modern processors... Not to mention the function call overhead. However, for puely aesthetical reasons: (Disclaimer: I'm not familiar (lack of time, sorry) with what disas_insn does apart from what is obviously implied by its name, so maybe the following may make any sense or not...) If it happens to be the case that disas_insn decodes the instruction and then proceeds to the native implementation of the opcode in question, if you used the table lookup only to find the function entry point and then paste its CONTENT on a code buffer and then concatenate this with the rest of the translated code, and the whole basic block would be run from there from that part on (caveat self-modifying code), then it would really clean up that piece of code. But I suspect it wouldn't be any faster than the current approach. --=20 "A year spent in artificial intelligence is enough to make one believe in God"-Alan J. Perlis 2005/4/17, Nathaniel G H : > Unless someone can show me that GCC produces table-lookups for the > switches in disas_insn(), there's a good opportunity for increased > speed by doing this manually. Do you agree with this assessment? >=20 > Please let me know if I'm on the right track. :-)