Re: [Qemu-devel] replacing dyngen (was: S/390 host fixed)

[Paul Brook]

On Wednesday 01 August 2007, Dan Shearer wrote:
> On Wed, Aug 01, 2007 at 02:02:13AM +0100, Paul Brook wrote:
> > I suspect making dyngen handle jump tables is not going to happen.
>
> Which brings up the question of dyngen. Very clever and a very good way
> of bootstrapping QEMU in the early days, but too brittle going forwards
> now the rest of QEMU works so well.
>
> You had an alternative approach to dyngen, pointed at here:
> http://lists.gnu.org/archive/html/qemu-devel/2006-10/msg00227.html
>
> Any thoughts about the future of hand-coded backends in QEMU? I wasn't
> convinced at first (and, given resources, it isn't nearly as good as a
> special-purpose language for describing CPUs at this level) but I now
> think your work is a very good solution for bootstrapping QEMU to the
> next level of users.

There's also a goolge SoC project to use llvm for code generation.
http://code.google.com/p/llvm-qemu/
This works, however it's also significantly slower than current qemu (no more 
than half the speed). It may be possible to improve this, but llvm is a 
fairly heavyweight framework so I'm not convinced it is ever going to be 
competitive for generalexecution speed.

One interesting thing that did come out of that project is that it's fairly 
trivial (a few hours work) to turn the existing code into a simple 
interpreter. Obviously this incurs a large performance hit, but also makes 
qemu trivially portable to other hosts.

My hand coded generator is currently ~20% slower that dyngen.
I still think this (or something similar) is the way forward, however I 
haven't made time to do any work on it recently. Some parts of this code 
effectively are a "special language" for describing a CPU, that happen to be 
implemented using the C preprocessor :-)

Paul