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

[Thomas Steffen <steffen.list.account@gmail.com>]

On 5/19/05, Paul Brook <paul@codesourcery.com> wrote:
> No. The problem is to turn machine code into (a different form of) machine
> code. A lot of the complexity in a compiler is involved with with turning the
> high-level language constructs into simple low-level machine operations.

I see your point. I did write a Z80 emulator on an early x86 once. The
flags where extremely close, and most commands have a direct
correspondency. You just have to decide on a register mapping, and you
can start. I wrote short assembler sequences for each command, very
much like the targets in qemu. But this is a special case: mapping one
architecture on a similar architecture.

Qemu is special an that it avoid both the problem in "papering over
the differences", and it avoids the combinatorial explosion of n
targets on m hosts. And it does this exactly because it uses C to
express machine commands, and not some other machine language. I think
you cannot take this away without changing the very nature of qemu.

The reason I care about this is that qemu has achived a lot more than
all other similar open source projects together. Look at bochs, or
plex86 or valgrind: they are nowhere near the performance of qemu, and
they only support x86 targets. So there must be something very
ingenious about the design of qemu, and I think it is the combination
of gcc and dyngen.

I certainly welcome every possible improvement, but I want to stress
how good qemu alread is.

> With qemu we're just translating from one simple form to another, so I'd argue
> that all you really need is a clever way of papering over the differences
> between the host and the guest.

So many projects have failed in this direction that I am tempted to
assume that this is a flawed approach. Apart from kqemu and VMware,
there is not one convincing solution even for the supposedly trivial
x86 on x86 case.

> What we have now (dyngen) is basically just an assembler. It maps qemu micro
> ops directly into blocks host code. The only reason dyngen uses gcc is to
> avoid having to hand write host encodings for all the ops.

It as also because C avoids the n by m problem. 

Thomas