From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DYsRX-0004LV-Ga for qemu-devel@nongnu.org; Thu, 19 May 2005 17:20:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DYsRW-0004KL-3w for qemu-devel@nongnu.org; Thu, 19 May 2005 17:20:34 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DYsNY-00020n-Oz for qemu-devel@nongnu.org; Thu, 19 May 2005 17:16:28 -0400 Received: from [64.233.184.198] (helo=wproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DYsJl-0002dq-0x for qemu-devel@nongnu.org; Thu, 19 May 2005 17:12:33 -0400 Received: by wproxy.gmail.com with SMTP id 71so910484wra for ; Thu, 19 May 2005 14:03:58 -0700 (PDT) Message-ID: Date: Thu, 19 May 2005 23:03:57 +0200 From: Thomas Steffen Subject: Re: [Qemu-devel] [patch] gcc4 host support In-Reply-To: <200505191952.48028.paul@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200505191644.54916.paul@codesourcery.com> <200505191952.48028.paul@codesourcery.com> Reply-To: Thomas Steffen , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 5/19/05, Paul Brook wrote: > No. The problem is to turn machine code into (a different form of) machin= e > 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 mi= cro > 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.=20 Thomas