From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DYlOE-0007bY-49 for qemu-devel@nongnu.org; Thu, 19 May 2005 09:48:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DYlOD-0007aU-5Z for qemu-devel@nongnu.org; Thu, 19 May 2005 09:48:41 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DYlKl-0004lG-5t for qemu-devel@nongnu.org; Thu, 19 May 2005 09:45:07 -0400 Received: from [65.74.133.9] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1DYl51-0002S5-06 for qemu-devel@nongnu.org; Thu, 19 May 2005 09:28:51 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [patch] gcc4 host support Date: Thu, 19 May 2005 14:20:16 +0100 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200505191420.16777.paul@codesourcery.com> 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 On Thursday 19 May 2005 08:23, Gwenole Beauchesne wrote: > Le mercredi, 18 mai 2005, =E0 22:48 Europe/Paris, Paul Brook a =E9crit : > > It's been said before that the long-term solution is to > > [incrementally] remove > > dyngen altogether, and replace it with a had-written code generator. > > I've discussed this in a bit more detail with Fabrice, and have an > > almost-working prototype implementation. When I get something that > > actually > > works I'll post it to the list for comments. > > Have you considered the VEX library? I have not tried it yet but it > looks promising. However, since it aims at providing a common IR, it > can miss certain optimizations related to condition codes (at least as > ppc guest). Do you have a URL? Neither google nor freshmeat.net turn up anything useful. > BTW, since dyngen-based JIT is fast enough both at compile time and at > run time, it could be used to gather stats for a higher optimizing JIT > (VEX or whatever). e.g. profiling branches in order to optimize hot > traces, providing hints for indirect branches, etc. One of the problems with dyngen is it is very fragile, see all the problems= =20 trying to make it work with gcc4. My initial goal with a JIT is to replace= =20 dyngen. The big advantage of dyngen is that it is very specialised to qemu. Even=20 though it's about the dumbest JIT implementation you can think of, it gets= =20 remarkably good results. Compare it with the Jikes RVM based ppc emulator=20 mentioned recently. The Jikes RVM has ~100 optimizations passes compared to= =20 dyngen which has 2 or 3. However the end result is still no better than=20 dyngen because most of that optimization effort is used to remove abstracti= on=20 that dygen doesn't introduce in the first place. It would be nice if we could use some sort of portable JIT library, however= I=20 think in reality a few qemu specific hacks(most of which we already use wit= h=20 dyngen) and a relatively dumb JIT are going to perform better. Paul