qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qemu vs gcc4
Date: Mon, 23 Oct 2006 19:37:42 +0100	[thread overview]
Message-ID: <200610231937.44676.paul@codesourcery.com> (raw)
In-Reply-To: <453D0428.9090809@palmsource.com>

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

  parent reply	other threads:[~2006-10-23 18:37 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-20 18:53 [Qemu-devel] qemu vs gcc4 K. Richard Pixley
2006-10-22 22:06 ` Johannes Schindelin
2006-10-23  8:16   ` Martin Guy
2006-10-23 12:20     ` Paul Brook
2006-10-23 13:59       ` Avi Kivity
2006-10-23 14:10         ` Paul Brook
2006-10-23 14:28           ` Avi Kivity
2006-10-23 14:31             ` Paul Brook
2006-10-23 14:35               ` Avi Kivity
2006-10-23 17:41     ` K. Richard Pixley
2006-10-23 17:58       ` Paul Brook
2006-10-23 18:04         ` K. Richard Pixley
2006-10-23 18:20           ` Laurent Desnogues
2006-10-23 18:37           ` Paul Brook [this message]
2006-10-24 23:39             ` Rob Landley
2006-10-25  0:24               ` Paul Brook
2006-10-25 19:39                 ` Rob Landley
2006-10-26 18:09                   ` Daniel Jacobowitz
2006-10-31 16:53             ` Rob Landley
2006-10-31 19:02               ` Paul Brook
2006-10-31 20:41                 ` Rob Landley
2006-10-31 22:08                   ` Paul Brook
2006-10-31 22:31                     ` Laurent Desnogues
2006-10-31 23:00                       ` Paul Brook
2006-11-01  0:00                     ` Rob Landley
2006-11-01  0:29                       ` Paul Brook
2006-11-01  1:51                         ` Rob Landley
2006-11-01  3:22                           ` Paul Brook
2006-11-01 16:34                             ` Rob Landley
2006-11-01 17:01                               ` Paul Brook
2006-10-31 23:17                 ` Rob Landley
2006-11-01  0:01                   ` Paul Brook
2006-10-30  4:35         ` Rob Landley
2006-10-30 14:56           ` Paul Brook
2006-10-30 16:31             ` Rob Landley
2006-10-30 16:50               ` Paul Brook
2006-10-30 22:54                 ` Stephen Torri
2006-10-30 23:13                   ` Paul Brook
2006-10-23  1:27 ` Rob Landley
2006-10-23  1:44   ` Paul Brook
2006-10-23  1:45   ` Johannes Schindelin
2006-10-23 17:53     ` K. Richard Pixley
2006-10-23 18:08     ` Rob Landley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200610231937.44676.paul@codesourcery.com \
    --to=paul@codesourcery.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).