From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1BieKs-0005gq-5L for qemu-devel@nongnu.org; Thu, 08 Jul 2004 15:13:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1BieKp-0005ge-Fx for qemu-devel@nongnu.org; Thu, 08 Jul 2004 15:13:33 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1BieKp-0005gb-Cf for qemu-devel@nongnu.org; Thu, 08 Jul 2004 15:13:31 -0400 Received: from [62.253.162.47] (helo=mta07-svc.ntlworld.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BieIG-0005GQ-KT for qemu-devel@nongnu.org; Thu, 08 Jul 2004 15:10:52 -0400 Received: from nemesis.frop.org ([62.253.132.150]) by mta07-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with ESMTP id <20040708191106.OQCM7085.mta07-svc.ntlworld.com@nemesis.frop.org> for ; Thu, 8 Jul 2004 20:11:06 +0100 From: Julian Seward Subject: Re: [Qemu-devel] Storing code caching Date: Thu, 8 Jul 2004 20:11:54 +0100 References: <1089306349.12383.1723.camel@aragorn> <431F9EDC-D108-11D8-8B8C-000A95B1EB4C@mac.com> In-Reply-To: <431F9EDC-D108-11D8-8B8C-000A95B1EB4C@mac.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200407082011.54991.jseward@acm.org> Reply-To: jseward@acm.org, 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 program I would write would basically use the qemu core to process > an entire executable, creating the blocks that are executable on the > host machine, and store them. Then start work on modifying qemu to > recognise the existense of the cache file and use the blocks. Then deal > with the self-modyfing code issue as above ... Nice idea, but ... I suspect it solves a non-problem really. Caching translations is only worthwhile when translation time is a large part of overall run time, but I bet that's not the case. It certainly isn't with Valgrind, which uses similar technology. If you want to throw lots of hacking effort at QEMU to make it go faster, I suspect you'll need to be building a more sophisticated code generator, a la "lcc" (http://www.cs.princeton.edu/software/lcc). That's a lot of work, though. J