From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Cs8Az-00043G-R1
	for qemu-devel@nongnu.org; Fri, 21 Jan 2005 18:26:49 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Cs8AM-0003mw-TX
	for qemu-devel@nongnu.org; Fri, 21 Jan 2005 18:26:12 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Cs8AH-0003h1-ST
	for qemu-devel@nongnu.org; Fri, 21 Jan 2005 18:26:05 -0500
Received: from [65.74.133.9] (helo=mail.codesourcery.com)
	by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.34) id 1Cs7tQ-0001E6-Uy
	for qemu-devel@nongnu.org; Fri, 21 Jan 2005 18:08:41 -0500
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] Re: MacOSX CVS build broken
Date: Fri, 21 Jan 2005 23:08:37 +0000
References: <BE0DEDA1.15F79%johnt@jdtangney.com>
	<1f1698a605011520285bc01970@mail.gmail.com>
	<pan.2005.01.21.22.38.42.149661@reply.to>
In-Reply-To: <pan.2005.01.21.22.38.42.149661@reply.to>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <200501212308.37792.paul@codesourcery.com>
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: qemu-devel@nongnu.org, daimon55@free.fr

>     d9d8:       4d 81 00 20     bgtlr
>     d9dc:       4b ff ff cc     b       d9a8 <op_pmaddwd_mmx+0x24>
>
> this really don't end with blr, but if I have understood correctly
> what I have found about bgtlr, it should do what blr do with some
> condition on r0.
> May be dyngen should verify on 4bffffcc too and not only 4e800020.

No, this is not correct.

The reason qemu expects the code sequence to end with blr is because it 
assumes the routine only has a single return statement at the end of the 
function. It then removes that return instructions to chain multiple ops 
together into a single block.

You'll notice that the preceding instruction is bgtlr, so simply accepting the 
"b" would break this assumtion.

The correct solution is to add FORCE_RET() to the end of the end of op_pmaddwd 
in ops_sse.h.

The same probably applies to many of the other routines in that file.

Paul