From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IxfjV-0001Wy-86 for qemu-devel@nongnu.org; Thu, 29 Nov 2007 04:30:57 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IxfjT-0001Un-D5 for qemu-devel@nongnu.org; Thu, 29 Nov 2007 04:30:56 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IxfjT-0001Ub-8b for qemu-devel@nongnu.org; Thu, 29 Nov 2007 04:30:55 -0500 Received: from pip15.gyao.ne.jp ([61.122.117.253] helo=mx.gate01.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IxfjS-0006Ft-Qh for qemu-devel@nongnu.org; Thu, 29 Nov 2007 04:30:55 -0500 Received: from [124.34.33.190] (helo=master.linux-sh.org) by smtp31.isp.us-com.jp with esmtp (Mail 4.41) id 1IxfjP-0006xJ-FO for qemu-devel@nongnu.org; Thu, 29 Nov 2007 18:30:51 +0900 Received: from localhost (unknown [127.0.0.1]) by master.linux-sh.org (Postfix) with ESMTP id 3917764C7C for ; Thu, 29 Nov 2007 09:30:42 +0000 (UTC) Received: from master.linux-sh.org ([127.0.0.1]) by localhost (master.linux-sh.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlVaXsmk7k9e for ; Thu, 29 Nov 2007 18:30:42 +0900 (JST) Date: Thu, 29 Nov 2007 18:30:41 +0900 From: Paul Mundt Subject: Re: [Qemu-devel] [PATCH]: sh4 delay slot code update Message-ID: <20071129093041.GA3030@linux-sh.org> References: <20071128124917.GA29926@linux-sh.org> <20071129055534.GA27339@linux-sh.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 On Thu, Nov 29, 2007 at 06:18:32PM +0900, Magnus Damm wrote: > On Nov 29, 2007 2:55 PM, Paul Mundt wrote: > > The T-state check for bt/bf happens _prior_ to execution of the delay > > slot instruction, while any delay-slot resident T-bit modifier is > > executed by the time we enter the branch. I don't know if your code > > handles that or not, but figured it's probably good to make that > > explicit. T-bit modifiers are always a bit hairy.. > > Yeah, the T flag is indeed a bit hairy. The patch should handle the T > bit exactly as you describe it. As part of the bt/bf instruction the T > flag is evaluated and if true the the DELAY_SLOT_TRUE bit is set. This > bit is later used to decide if we should jump or not after the delay > slot instruction. > Ok, I have no objection to these changes then.