From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ixcsr-0000bM-0h for qemu-devel@nongnu.org; Thu, 29 Nov 2007 01:28:25 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ixcsp-0000au-8r for qemu-devel@nongnu.org; Thu, 29 Nov 2007 01:28:23 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ixcsp-0000an-43 for qemu-devel@nongnu.org; Thu, 29 Nov 2007 01:28:23 -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 1Ixcso-0004Ra-Jm for qemu-devel@nongnu.org; Thu, 29 Nov 2007 01:28:23 -0500 Received: from [124.34.33.190] (helo=master.linux-sh.org) by smtp31.isp.us-com.jp with esmtp (Mail 4.41) id 1Ixcsk-0006G4-GI for qemu-devel@nongnu.org; Thu, 29 Nov 2007 15:28:18 +0900 Received: from localhost (unknown [127.0.0.1]) by master.linux-sh.org (Postfix) with ESMTP id C827964C7C for ; Thu, 29 Nov 2007 05:55:34 +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 xU-AxQ3yVgAH for ; Thu, 29 Nov 2007 14:55:34 +0900 (JST) Date: Thu, 29 Nov 2007 14:55:34 +0900 From: Paul Mundt Subject: Re: [Qemu-devel] [PATCH]: sh4 delay slot code update Message-ID: <20071129055534.GA27339@linux-sh.org> References: <20071128124917.GA29926@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 02:43:03PM +0900, Magnus Damm wrote: > On Nov 28, 2007 9:49 PM, Paul Mundt wrote: > I was mainly wondering if I really needed to save the state of SR_T, > but I assumed so. So the code should be correct. And yes, I'm sure > there are quite a few slottable instructions with interesting side > effects, but that's a separate issue. > The only thing to be careful of is the ordering semantics for the T-bit state, which is what I tried to convey in the code snippet. > > You can see an example in arch/sh/kernel/entry-common.S: > > > > syscall_exit_work: > > ! r0: current_thread_info->flags > > ! r8: current_thread_info > > tst #_TIF_SYSCALL_TRACE | _TIF_SINGLESTEP | _TIF_SYSCALL_AUDIT, r0 > > bt/s work_pending > > tst #_TIF_NEED_RESCHED, r0 > > > > .... > > work_pending: > > ! r0: current_thread_info->flags > > ! r8: current_thread_info > > ! t: result of "tst #_TIF_NEED_RESCHED, r0" > > bf/s work_resched > > tst #(_TIF_SIGPENDING | _TIF_RESTORE_SIGMASK), r0 > > So while bt/s is conditional on the first flag test, the T-state is relative to the second test by the time the branch happens. 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..