Re: [Qemu-devel] [patch] gcc4 host support

[Paul Brook <paul@codesourcery.com>]

On Thursday 19 May 2005 08:23, Gwenole Beauchesne wrote:
> Le mercredi, 18 mai 2005, à 22:48 Europe/Paris, Paul Brook a écrit :
> > It's been said before that the long-term solution is to
> > [incrementally] remove
> > dyngen altogether, and replace it with a had-written code generator.
> > I've discussed this in a bit more detail with Fabrice, and have an
> > almost-working prototype implementation. When I get something that
> > actually
> > works I'll post it to the list for comments.
>
> Have you considered the VEX library? I have not tried it yet but it
> looks promising. However, since it aims at providing a common IR, it
> can miss certain optimizations related to condition codes (at least as
> ppc guest).

Do you have a URL? Neither google nor freshmeat.net turn up anything useful.

> BTW, since dyngen-based JIT is fast enough both at compile time and at
> run time, it could be used to gather stats for a higher optimizing JIT
> (VEX or whatever). e.g. profiling branches in order to optimize hot
> traces, providing hints for indirect branches, etc.

One of the problems with dyngen is it is very fragile, see all the problems 
trying to make it work with gcc4. My initial goal with a JIT is to replace 
dyngen.

The big advantage of dyngen is that it is very specialised to qemu. Even 
though it's about the dumbest JIT implementation you can think of, it gets 
remarkably good results. Compare it with the Jikes RVM based ppc emulator 
mentioned recently. The Jikes RVM has ~100 optimizations passes compared to 
dyngen which has 2 or 3. However the end result is still no better than 
dyngen because most of that optimization effort is used to remove abstraction 
that dygen doesn't introduce in the first place.

It would be nice if we could use some sort of portable JIT library, however I 
think in reality a few qemu specific hacks(most of which we already use with 
dyngen) and a relatively dumb JIT are going to perform better.

Paul