From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1Cgm3a-0007Ps-OA for qemu-devel@nongnu.org; Tue, 21 Dec 2004 10:36:14 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1Cgm3a-0007Pg-Am for qemu-devel@nongnu.org; Tue, 21 Dec 2004 10:36:14 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1Cgm3a-0007Pd-73 for qemu-devel@nongnu.org; Tue, 21 Dec 2004 10:36:14 -0500 Received: from [65.74.133.9] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1Cglr6-0006SY-AN for qemu-devel@nongnu.org; Tue, 21 Dec 2004 10:23:20 -0500 From: Paul Brook Date: Tue, 21 Dec 2004 15:23:11 +0000 References: <20041215134754.GA28410@100tka.net> <1103565756.18531.838.camel@aragorn> <41C76080.3000707@bellard.org> In-Reply-To: <41C76080.3000707@bellard.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200412211523.11342.paul@codesourcery.com> Subject: [Qemu-devel] Re: Removing GCC dependency 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 always thought the current 'dyngen' solution as a temporary one > because it enabled a fast developpement of QEMU as the expense of > performance (this is relative of course, QEMU is already quite fast and > usable). But if we want better performances and better... portability > (in the sense that we are not tied to a specific GCC version), then a > hand coded code generator is the only way to go. Do we also want to aim towards using the same code generator for all guest cpus? We currently have separate op.c for each emulated architecture. Combining these into a single set of opcodes seems like a good idea. Once we start doing hand coded generator and/or nontrivial optimisations on the generated opcodes the duplications is really going to hurt, and the bar for adding new architectures will be significantly higher. I realise there complications with this (different register files and MMU types), but I can see large benefits if these can be overcome. Paul