From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Bm0kc-0004IR-Is for qemu-devel@nongnu.org; Sat, 17 Jul 2004 21:46:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Bm0ka-0004IF-TH for qemu-devel@nongnu.org; Sat, 17 Jul 2004 21:46:02 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Bm0ka-0004IC-PP for qemu-devel@nongnu.org; Sat, 17 Jul 2004 21:46:00 -0400 Received: from [207.217.120.123] (helo=swan.mail.pas.earthlink.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Bm0hr-0000qh-4P for qemu-devel@nongnu.org; Sat, 17 Jul 2004 21:43:11 -0400 Received: from 0-1pool56-46.nas3.oklahoma-city1.ok.us.da.qwest.net ([63.156.56.46] helo=computername) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Bm0hY-0003pD-00 for qemu-devel@nongnu.org; Sat, 17 Jul 2004 18:42:55 -0700 Message-ID: <001001c46c68$81f01510$2e389c3f@computername> From: "syeng" Date: Sat, 17 Jul 2004 20:42:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Perhaps a Virtual CPU for host? 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 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?