From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Bm0xk-0006Ms-7h for qemu-devel@nongnu.org; Sat, 17 Jul 2004 21:59:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Bm0xi-0006Ma-99 for qemu-devel@nongnu.org; Sat, 17 Jul 2004 21:59:35 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Bm0xh-0006MV-H5 for qemu-devel@nongnu.org; Sat, 17 Jul 2004 21:59:33 -0400 Received: from [38.113.3.61] (helo=babyruth.hotpop.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Bm0v4-00026J-BJ for qemu-devel@nongnu.org; Sat, 17 Jul 2004 21:56:50 -0400 Received: from phreaker.net (kubrick.hotpop.com [38.113.3.103]) by babyruth.hotpop.com (Postfix) with SMTP id 2CDF86DE4CF for ; Sun, 18 Jul 2004 01:09:50 +0000 (UTC) Received: from jbrown.mylinuxbox.org (pcp03144805pcs.midval01.tn.comcast.net [68.59.228.236]) by smtp-2.hotpop.com (Postfix) with ESMTP id 654F26C64FE for ; Sun, 18 Jul 2004 01:09:48 +0000 (UTC) Date: Sat, 17 Jul 2004 21:56:24 -0400 From: "Jim C. Brown" Subject: Re: [Qemu-devel] Perhaps a Virtual CPU for host? Message-ID: <20040718015624.GA10404@jbrown.mylinuxbox.org> References: <001001c46c68$81f01510$2e389c3f@computername> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001001c46c68$81f01510$2e389c3f@computername> Reply-To: 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 Sat, Jul 17, 2004 at 08:42:13PM -0500, syeng wrote: > I'm a lurker in this list and I'm not a developer, so please excuse me if > this isn't a good idea. > > I've been wondering... Since Qemu is a binary translator, would it be > reasonable to have Qemu generate code for a virtual cpu instead of a real > cpu? > > Then the program would run the virtual cpu emulator, which runs the code > generated by qemu. > > In other words... No more back-ends for PPC, x86, Sparc, etc. etc. Porting > to a new system would be easier, too. > > Now, I know it sounds pretty bad. > > BUT, I was thinking that if you chose the right virtual cpu architecture, > you might actually be able to get pretty decent performance out it. I've > heard of cases where virtual cpu's ran benchmarks pretty well because each > instruction was easily decoded and each instruction did a lot of 'work' > (CISC vs. RISC. For a virtual cpu, CISC style cpu's are better, I guess.) > > I don't know how efficient the code is that Qemu generates, but it certainly > wouldn't be extremely efficient. Perhaps a carefully chosen virtual cpu > architecture might make up for some of that, and perhaps run as fast as half > the speed of a native Qemu port? > > If nothing else, it might provide a generic base for currently unsupported > host systems. > > Any comments? > It should be fairly simple to modify the current qemu-system-i386 code and make a qemu-system-a386 version. The a386 (http://a386.nocrew.org/) is a virtual abstraction of the traditional i386 instruction set implemented in C, but it is slightly cleaner. a386 hasn't been updated in a while but its open source, so if you are really interested this is a good place to start. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection.