From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ea1e0-00019S-Pm for qemu-devel@nongnu.org; Wed, 09 Nov 2005 20:54:28 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ea1dz-00019D-5V for qemu-devel@nongnu.org; Wed, 09 Nov 2005 20:54:28 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ea1dz-00019A-48 for qemu-devel@nongnu.org; Wed, 09 Nov 2005 20:54:27 -0500 Received: from [128.8.10.163] (helo=po1.wam.umd.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Ea1dz-0008H0-Dy for qemu-devel@nongnu.org; Wed, 09 Nov 2005 20:54:27 -0500 Date: Wed, 9 Nov 2005 20:54:12 -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: <20051110015412.GA641@jbrown.mylinuxbox.org> References: <43724B52.3050101@mail.ru> <200511091945.26239.paul@codesourcery.com> <4372532E.4090104@mail.ru> <200511100133.55709.jseward@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200511100133.55709.jseward@acm.org> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Julian Seward Cc: qemu-devel@nongnu.org On Thu, Nov 10, 2005 at 01:33:55AM +0000, Julian Seward 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 > as to be independent future changes in gcc, and generally more robust? > > J > Yes, Paul Brook is working on it. > On Wednesday 09 November 2005 19:51, Igor Kovalenko wrote: > > Paul Brook wrote: > > >> Notice the 'repz mov' sequence, which seems to be undocumented > > >> instruction. It seems to work somehow but chokes valgrind decoder. > > >> The following patch (against current CVS) fixes this problem, > > > > > > This patch is incorrect. > > > > > > It could match any number of other instructions that happen to end in > > > 0xf3. eg > > > > > > 0: c7 45 00 00 00 00 f3 movl $0xf3000000,0x0(%ebp) > > > 7: c3 ret > > > > > > IIRC the "rep; ret" sequence is to avoid a pipeline stall on Athlon CPUs. > > > Try tuning for a different CPU. > > > > > > Paul > > > > > >> Index: dyngen.c > > >> =================================================================== > > >> RCS file: /cvsroot/qemu/qemu/dyngen.c,v > > >> retrieving revision 1.40 > > >> diff -u -r1.40 dyngen.c > > >> --- dyngen.c 27 Apr 2005 19:55:58 -0000 1.40 > > >> +++ dyngen.c 9 Nov 2005 19:12:38 -0000 > > >> @@ -1387,6 +1387,12 @@ > > >> error("empty code for %s", name); > > >> if (p_end[-1] == 0xc3) { > > >> len--; > > >> + /* This can be 'rep ; ret' optimized return sequence, > > >> + * need to check further and strip the 'rep' prefix > > >> + */ > > >> + if (len != 0 && p_end[-2] == 0xf3) { > > >> + len--; > > >> + } > > >> } else { > > >> error("ret or jmp expected at the end of %s", name); > > >> } > > > > OK I missed that... > > Then a discussion about gcc-4 turns into something much more interesting :) > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection.