From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1EZvyW-0003xc-R9
	for qemu-devel@nongnu.org; Wed, 09 Nov 2005 14:51:16 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1EZvyT-0003w7-AE
	for qemu-devel@nongnu.org; Wed, 09 Nov 2005 14:51:16 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1EZvyT-0003w3-3E
	for qemu-devel@nongnu.org; Wed, 09 Nov 2005 14:51:13 -0500
Received: from [195.34.32.124] (helo=Apachihuilliztli.mtu.ru)
	by monty-python.gnu.org with esmtp (Exim 4.34) id 1EZvyT-0007om-9u
	for qemu-devel@nongnu.org; Wed, 09 Nov 2005 14:51:13 -0500
Message-ID: <4372532E.4090104@mail.ru>
Date: Wed, 09 Nov 2005 22:51:10 +0300
From: Igor Kovalenko <garrison@mail.ru>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] patch for qemu with newer gcc-3.4.x (support repz
	retq optimization for amd processors correctly)
References: <43724B52.3050101@mail.ru>
	<200511091945.26239.paul@codesourcery.com>
In-Reply-To: <200511091945.26239.paul@codesourcery.com>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org

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 :)

-- 
Kind regards,
Igor V. Kovalenko