From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gc4gJ-0001rY-4e for qemu-devel@nongnu.org; Mon, 23 Oct 2006 14:37:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gc4gH-0001qS-5U for qemu-devel@nongnu.org; Mon, 23 Oct 2006 14:37:50 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gc4gG-0001qM-Up for qemu-devel@nongnu.org; Mon, 23 Oct 2006 14:37:48 -0400 Received: from [65.74.133.4] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1Gc4gG-0000Nh-Px for qemu-devel@nongnu.org; Mon, 23 Oct 2006 14:37:49 -0400 From: Paul Brook Subject: Re: [Qemu-devel] qemu vs gcc4 Date: Mon, 23 Oct 2006 19:37:42 +0100 References: <45391B22.1050608@palmsource.com> <200610231858.32157.paul@codesourcery.com> <453D0428.9090809@palmsource.com> In-Reply-To: <453D0428.9090809@palmsource.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200610231937.44676.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 Monday 23 October 2006 19:04, K. Richard Pixley wrote: > Paul Brook wrote: > > Better to just teach qemu how to generate code. > > In fact I've already done most of the infrastructure (and a fair amount > > of the legwork) for this. The only major missing function is code to do > > softmmu load/store ops. > > https://nowt.dyndns.org/ > > Well, perhaps. Except that with gcc, we get to leverage the ongoing gcc > optimizations, bug fixes, new cpu support, debugger support, etc. > Granted, not all of these are going to be relevant to the qemu > environment, but in a contest between gcc generated code and qemu > generated code, I'll bet on gcc most days. > > No doubt there are times when a gcc optimization takes so long that it > costs more time to optimize than would be won back by the running code. = =A0 > Presumably, qemu generated code would be able to make better decisions > here. =A0Except that we're not talking about using gcc in real time, are > we? =A0So essentially we have near infinite time for optimizations. The code we're talking about (op.c) is sufficiently small and simple that=20 there's nothing the compiler can do with it. In fact many of the ops map=20 directly onto a single assembly instruction. To get better translated code we need to do inter-op optimization as code i= s=20 translated (even if it's only simple things like register allocation). This= =20 requires qemu be able to generate code at runtime. Using the gcc backends for dynamic code generation isn't a realistic option= =2E=20 They're simply too heavyweight to be used "in real time". qemu needs to be= =20 able to efficiently generate short, simple code blocks. Most of the gcc=20 infrastructure is for optimizations that take longer to run than we're ever= =20 going to get back in improved performance. I did look at integrating an existing JIT compiler into qemu, but couldn't= =20 find one that fitted nicely, and allowed an incremental conversion. It turn out that qemu already does most of the hard work, and a code=20 generation backend is fairly simple. The diff for my current implementation= =20 is <2k lines of common code, plus <1k lines for each of x86, amd64 and ppc3= 2=20 hosts. Paul