From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ea1Fm-0005iq-Mp for qemu-devel@nongnu.org; Wed, 09 Nov 2005 20:29:26 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ea1Fi-0005ic-Tq for qemu-devel@nongnu.org; Wed, 09 Nov 2005 20:29:26 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ea1Fh-0005iZ-Um for qemu-devel@nongnu.org; Wed, 09 Nov 2005 20:29:22 -0500 Received: from [81.103.221.47] (helo=mta07-winn.ispmail.ntl.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Ea1Fh-0006sy-Ru for qemu-devel@nongnu.org; Wed, 09 Nov 2005 20:29:22 -0500 Received: from aamta12-winn.ispmail.ntl.com ([81.103.221.35]) by mta07-winn.ispmail.ntl.com with ESMTP id <20051110012920.NAVI21883.mta07-winn.ispmail.ntl.com@aamta12-winn.ispmail.ntl.com> for ; Thu, 10 Nov 2005 01:29:20 +0000 Received: from suse10.valgrind.org ([80.4.6.170]) by aamta12-winn.ispmail.ntl.com with ESMTP id <20051110012920.PCMC11910.aamta12-winn.ispmail.ntl.com@suse10.valgrind.org> for ; Thu, 10 Nov 2005 01:29:20 +0000 From: Julian Seward Subject: Re: [Qemu-devel] patch for qemu with newer gcc-3.4.x (support repz retq optimization for amd processors correctly) Date: Thu, 10 Nov 2005 01:33:55 +0000 References: <43724B52.3050101@mail.ru> <200511091945.26239.paul@codesourcery.com> <4372532E.4090104@mail.ru> In-Reply-To: <4372532E.4090104@mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <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: qemu-devel@nongnu.org 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 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 :)