[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] qemu vs gcc4
From: |
Paul Brook |
Subject: |
Re: [Qemu-devel] qemu vs gcc4 |
Date: |
Mon, 23 Oct 2006 19:37:42 +0100 |
User-agent: |
KMail/1.9.5 |
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.
> Presumably, qemu generated code would be able to make better decisions
> here. Except that we're not talking about using gcc in real time, are
> we? So essentially we have near infinite time for optimizations.
The code we're talking about (op.c) is sufficiently small and simple that
there's nothing the compiler can do with it. In fact many of the ops map
directly onto a single assembly instruction.
To get better translated code we need to do inter-op optimization as code is
translated (even if it's only simple things like register allocation). This
requires qemu be able to generate code at runtime.
Using the gcc backends for dynamic code generation isn't a realistic option.
They're simply too heavyweight to be used "in real time". qemu needs to be
able to efficiently generate short, simple code blocks. Most of the gcc
infrastructure is for optimizations that take longer to run than we're ever
going to get back in improved performance.
I did look at integrating an existing JIT compiler into qemu, but couldn't
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
generation backend is fairly simple. The diff for my current implementation
is <2k lines of common code, plus <1k lines for each of x86, amd64 and ppc32
hosts.
Paul
- Re: [Qemu-devel] qemu vs gcc4, (continued)
- Re: [Qemu-devel] qemu vs gcc4, Paul Brook, 2006/10/23
- Re: [Qemu-devel] qemu vs gcc4, Avi Kivity, 2006/10/23
- Re: [Qemu-devel] qemu vs gcc4, Paul Brook, 2006/10/23
- Re: [Qemu-devel] qemu vs gcc4, Avi Kivity, 2006/10/23
- Re: [Qemu-devel] qemu vs gcc4, Paul Brook, 2006/10/23
- Re: [Qemu-devel] qemu vs gcc4, Avi Kivity, 2006/10/23
- Re: [Qemu-devel] qemu vs gcc4, K. Richard Pixley, 2006/10/23
- Re: [Qemu-devel] qemu vs gcc4, Paul Brook, 2006/10/23
- Re: [Qemu-devel] qemu vs gcc4, K. Richard Pixley, 2006/10/23
- Re: [Qemu-devel] qemu vs gcc4, Laurent Desnogues, 2006/10/23
- Re: [Qemu-devel] qemu vs gcc4,
Paul Brook <=
- Re: [Qemu-devel] qemu vs gcc4, Rob Landley, 2006/10/24
- Re: [Qemu-devel] qemu vs gcc4, Paul Brook, 2006/10/24
- Re: [Qemu-devel] qemu vs gcc4, Rob Landley, 2006/10/25
- Re: [Qemu-devel] qemu vs gcc4, Daniel Jacobowitz, 2006/10/26
- Re: [Qemu-devel] qemu vs gcc4, Rob Landley, 2006/10/31
- Re: [Qemu-devel] qemu vs gcc4, Paul Brook, 2006/10/31
- Re: [Qemu-devel] qemu vs gcc4, Rob Landley, 2006/10/31
- Re: [Qemu-devel] qemu vs gcc4, Paul Brook, 2006/10/31
- Re: [Qemu-devel] qemu vs gcc4, Laurent Desnogues, 2006/10/31
- Re: [Qemu-devel] qemu vs gcc4, Paul Brook, 2006/10/31