From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IhYdc-00017d-Fg for qemu-devel@nongnu.org; Mon, 15 Oct 2007 18:42:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IhYdb-00016e-4U for qemu-devel@nongnu.org; Mon, 15 Oct 2007 18:42:16 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IhYda-00016O-Pj for qemu-devel@nongnu.org; Mon, 15 Oct 2007 18:42:14 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IhYda-0005zH-8P for qemu-devel@nongnu.org; Mon, 15 Oct 2007 18:42:14 -0400 From: Paul Brook Subject: Re: [Qemu-devel] RFC: Code fetch optimisation Date: Mon, 15 Oct 2007 23:42:06 +0100 References: <1192362267.9976.383.camel@rapid> <200710151701.17822.paul@codesourcery.com> <1192483833.9976.456.camel@rapid> In-Reply-To: <1192483833.9976.456.camel@rapid> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710152342.08019.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 Cc: "J. Mayer" > > VLE targets (x86, m68k) can translate almost a full page of instructions, > > and a page boundary can be anywhere within that block. Once we've spanned > > multiple pages there's not point stopping translation immediately. We may > > as well translate as many instructions as we can on the second page. > > > > I'd guess most TB are much smaller than a page, so on average only a few > > instructions are going to come after the page boundary. > > This leads me to another reflexion. For fixed length encoding targets, > we always stop translation when reaching a page boundary. If we keep > using the current model and we optimize the slow case, it would be > possible to stop only if we cross 2 pages boundary during code > translation, and it seems that this case is not likely to happen. If we > keep the current behavior, we could remove the second page_addr element > in the tb structure and maybe optimize parts of the tb management and > invalidation code. The latter may be the only feasible option. Some targets (ARMv5, maybe others) do not have an explicit fault address for MMU instruction faults. The faulting address is the address of the current instruction when the fault occurs. Prefetch aborts are generated at translation time, which effectively means the faulting instruction must be at the start of a TB. Terminating the TB on a page boundary guarantees this behavior. For VLE targets we already get this wrong (the prefetch abort occurs some time before the faulting instruction executes). I don't know if this behavior is permitted by the ISA, but it's definitely possible to construct cases where it has visible effect. Paul