From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CgmEu-0004PM-98 for qemu-devel@nongnu.org; Tue, 21 Dec 2004 10:47:56 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CgmEq-0004Mx-EN for qemu-devel@nongnu.org; Tue, 21 Dec 2004 10:47:52 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CgmEq-0004Mf-7g for qemu-devel@nongnu.org; Tue, 21 Dec 2004 10:47:52 -0500 Received: from [212.16.62.51] (helo=mail.13thfloor.at) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Cgm40-0003LI-Rh for qemu-devel@nongnu.org; Tue, 21 Dec 2004 10:36:41 -0500 Date: Tue, 21 Dec 2004 16:36:33 +0100 From: Herbert Poetzl Subject: Re: [Qemu-devel] Re: Removing GCC dependency Message-ID: <20041221153633.GB9802@mail.13thfloor.at> References: <20041215134754.GA28410@100tka.net> <1103565756.18531.838.camel@aragorn> <41C76080.3000707@bellard.org> <200412211523.11342.paul@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200412211523.11342.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org On Tue, Dec 21, 2004 at 03:23:11PM +0000, Paul Brook wrote: > > 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. > again a look at 'other' binary translators like the bintrans[1] could provide some good ideas ... best, Herbert -- from the README -- Machine Descriptions -------------------- bintrans uses machine descriptions to automatically generate interpreters, disassemblers, composer macros, and liveness analysers. Currently, there are machine descriptions for the i386, the PPC and the Alpha, residing in the files "i386.lisp", "ppc.lisp", and "alpha.lisp", respectively. Should you choose to play around with them, here's how to generate the various C files from them: 1. Start CLISP 2. (load "init.lisp") then: 3a. (generate-all-alpha-files) ; to generate the Alpha files 3b. (generate-all-ppc-files) ; to generate the PPC files 3c. (generate-all-intel-files) ; to generate the i386 files > Paul > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel