[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [patch] gcc4 host support
From: |
Thomas Steffen |
Subject: |
Re: [Qemu-devel] [patch] gcc4 host support |
Date: |
Thu, 19 May 2005 23:03:57 +0200 |
On 5/19/05, Paul Brook <address@hidden> 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
- Re: [Qemu-devel] [patch] gcc4 host support, (continued)
- Re: [Qemu-devel] [patch] gcc4 host support, Gwenole Beauchesne, 2005/05/19
- Re: [Qemu-devel] [patch] gcc4 host support, Paul Brook, 2005/05/19
- Re: [Qemu-devel] [patch] gcc4 host support, Gwenole Beauchesne, 2005/05/19
- Re: [Qemu-devel] [patch] gcc4 host support, Paul Brook, 2005/05/19
- Re: [Qemu-devel] [patch] gcc4 host support, Thomas Steffen, 2005/05/19
- Re: [Qemu-devel] [patch] gcc4 host support, Paul Brook, 2005/05/19
- Re: [Qemu-devel] [patch] gcc4 host support, Tim Walker, 2005/05/19
- Re: [Qemu-devel] [patch] gcc4 host support, Paul Brook, 2005/05/19
- Re: [Qemu-devel] [patch] gcc4 host support,
Thomas Steffen <=
- Re: [Qemu-devel] [patch] gcc4 host support, John Hogerhuis, 2005/05/19
- Re: [Qemu-devel] [patch] gcc4 host support, Thomas Steffen, 2005/05/20
- Re: [Qemu-devel] [patch] gcc4 host support, Paul Brook, 2005/05/20
- Re: [Qemu-devel] [patch] gcc4 host support, Ian Rogers, 2005/05/19
- Re: [Qemu-devel] [patch] gcc4 host support, McMullan, Jason, 2005/05/19