Re: [Qemu-devel] Automatic generation of code-generator components (RETRY)

[Eliot Moss]

On 7/20/2010 6:14 PM, Blue Swirl wrote:

> If you keep the development process open, with patches, RFCs and other
> proposals flowing regularly to upstream QEMU, I'd suppose the
> developer community would welcome this. But there have been several
> forks of QEMU and merging those looks hard. The problem with those was
> that the development was kept behind a curtain until it was 'finished'
> according to some internal standards and then it was presented to us
> as something that should just be swallowed in whole. In the continuous
> cooperation model the result will be seamless. It's also possible that
> there's too much mismatch between the goals of the projects, but with
> early involvement of both sides, it can be detected before it's too
> late.

Yes, I agree that an incremental and open process will work much
better.  Obviously we'd need to learn the local customs :-) , but
I expect we'd start with one or two of the existing guests and
hosts, not replacing the current code but doing something like
using a different but related name.  Among other things, we'd
probably want a scheme where we could test our code side by side
a known-working version at the start -- an interesting challenge,
but perhaps not too hard if we give it some thought.  Anyway,
yes, it's important not to present something that is a huge change,
in one gulp, without experience-building and confidence-building
steps in the middle.

> I think this case is interesting for the currently unimplemented
> hosts, or if the performance is improved from existing hosts compared
> to TCG. The extra optimization pass may waste time which will not be
> gained back by faster execution time of the better generated code.
> There's also KVM, which should be always the fastest for cases where
> host and target CPUs match.

We can experiment some with different degrees of (simple)
optimization, though I expect TCG probably already chose
a sweet spot.  I am not familiar yet with KVM and should
become more so.  I gather that it is the case where guest
and host are the same, which indeed gives rise to both
unique opportunities and unique challenges in performance.
However, I remain confident that we can "encode" suitable
strategies with our tool.

You are right, though, that the most promise is for new
ISAs.  We probably cannot do much better than TCG front-ends
and back-ends tuned by experts.  However, the ease of
reworking various details may make it easier to tune and
possibly do a little better; certainly with new ISAs.

> Again, current implementations basically consist of just a huge C
> switch statement, so it's hard to improve performance from that.
> Enabling new targets would be interesting though, or maybe one day an
> automatically generated translator could beat a hand written one.

Agreed.

Again, thanks for your encouraging reply and your very
thoughtful and useful suggestions.  I have been pleased to
find this a polite community -- sad that not all open
source communities are so polite and friendly!

Best wishes -- Eliot Moss