From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ea3E8-00017R-V0 for qemu-devel@nongnu.org; Wed, 09 Nov 2005 22:35:53 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ea3E7-000173-Dc for qemu-devel@nongnu.org; Wed, 09 Nov 2005 22:35:52 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ea3E7-00016z-AP for qemu-devel@nongnu.org; Wed, 09 Nov 2005 22:35:51 -0500 Received: from [128.8.10.163] (helo=po1.wam.umd.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Ea3E7-0006Tn-G9 for qemu-devel@nongnu.org; Wed, 09 Nov 2005 22:35:51 -0500 Date: Wed, 9 Nov 2005 22:35:46 -0500 From: "Jim C. Brown" Subject: Re: [Qemu-devel] patch for qemu with newer gcc-3.4.x (support repz retq optimization for amd processors correctly) Message-ID: <20051110033546.GA1424@jbrown.mylinuxbox.org> References: <43724B52.3050101@mail.ru> <200511091945.26239.paul@codesourcery.com> <4372532E.4090104@mail.ru> <200511100133.55709.jseward@acm.org> <20051110014404.GC2321@mail.shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051110014404.GC2321@mail.shareable.org> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: qemu-devel@nongnu.org On Thu, Nov 10, 2005 at 01:44:04AM +0000, Jamie Lokier wrote: > > > > The use of gcc to generate the back end in QEMU's early days was a > > clever way to get the project up and running quickly. But surely > > now it would be better to transition to a handwritten backend, so > > It should be trivial to take the _currently_ generated GCC code for > all the architectures QEMU is commonly built on, and just distribute > that code with the QEMU source. > You mean convert the code with gcc 3 into asm, and then distribute that? I'm no expert, but I would imagine such a solution would be quite brittle. That's assuming one can make gcc 3 assembly code work with gcc 4 (5?) code to form a single object file. > Then it would be independent of future changes to GCC. Well, someone would still need to maintain all those assembly files. Or else keep an old copy of gcc 3 around to regenerate them whenever needed. > > I understand a handwritten backend is already being written. But > until a proper one is done, wouldn't that serve as a useful stopgap? > I believe the current version works - but it doesn't implement every possible op yet. For now, it relies on dyngen to produce the missing ops (until they are replaced with the hand coded version). > -- Jamie > -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection.