Re: [Qemu-devel] qemu vs gcc4

[Paul Brook]

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