From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IgMKp-0000rh-8d for qemu-devel@nongnu.org; Fri, 12 Oct 2007 11:21:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IgMKk-0000mB-Tg for qemu-devel@nongnu.org; Fri, 12 Oct 2007 11:21:54 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IgMKk-0000m1-OR for qemu-devel@nongnu.org; Fri, 12 Oct 2007 11:21:50 -0400 Received: from wr-out-0506.google.com ([64.233.184.226]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IgMKk-0007ZK-KZ for qemu-devel@nongnu.org; Fri, 12 Oct 2007 11:21:50 -0400 Received: by wr-out-0506.google.com with SMTP id c38so1311706wra for ; Fri, 12 Oct 2007 08:21:49 -0700 (PDT) Message-ID: Date: Fri, 12 Oct 2007 18:21:47 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] RFC: Code fetch optimisation In-Reply-To: <1192178037.9976.259.camel@rapid> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1192178037.9976.259.camel@rapid> 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 10/12/07, J. Mayer wrote: > Here's a small patch that allow an optimisation for code fetch, at least > for RISC CPU targets, as suggested by Fabrice Bellard. > The main idea is that a translated block is never to span over a page > boundary. As the tb_find_slow routine already gets the physical address > of the page of code to be translated, the code translator could then > fetch the code using raw host memory accesses instead of doing it > through the softmmu routines. > This patch could also be adapted to RISC CPU targets, with care for the > last instruction of a page. For now, I did implement it for alpha, arm, > mips, PowerPC and SH4. > I don't actually know if the optimsation would bring a sensible speed > gain or if it will be absolutelly marginal. > > Please comment. This will not work correctly for execution of MMIO registers, but maybe that won't work on real hardware either. Who cares. Wouldn't it be even more efficient if you moved most of this calculation: + phys_pc = (unsigned long)phys_ram_base + tb->page_addr[0] + + (pc_start & ~TARGET_PAGE_MASK); here: + tb->page_addr[0] = phys_page1; ?