From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IxMM9-0001Ax-An for qemu-devel@nongnu.org; Wed, 28 Nov 2007 07:49:33 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IxMM8-0001AF-5W for qemu-devel@nongnu.org; Wed, 28 Nov 2007 07:49:32 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IxMM7-0001A6-Rl for qemu-devel@nongnu.org; Wed, 28 Nov 2007 07:49:31 -0500 Received: from pip9.gyao.ne.jp ([61.122.117.247] 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 1IxMM7-0001Kr-7D for qemu-devel@nongnu.org; Wed, 28 Nov 2007 07:49:31 -0500 Received: from [124.34.33.190] (helo=master.linux-sh.org) by smtp33.isp.us-com.jp with esmtp (Mail 4.41) id 1IxMM1-000862-Qh for qemu-devel@nongnu.org; Wed, 28 Nov 2007 21:49:25 +0900 Received: from localhost (unknown [127.0.0.1]) by master.linux-sh.org (Postfix) with ESMTP id E75E064C7C for ; Wed, 28 Nov 2007 12:49:17 +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 76qxh2Af90mJ for ; Wed, 28 Nov 2007 21:49:17 +0900 (JST) Date: Wed, 28 Nov 2007 21:49:17 +0900 From: Paul Mundt Subject: Re: [Qemu-devel] [PATCH]: sh4 delay slot code update Message-ID: <20071128124917.GA29926@linux-sh.org> References: 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 Wed, Nov 28, 2007 at 06:54:20PM +0900, Magnus Damm wrote: > +#define DELAY_SLOT_TRUE (1 << 2) > +#define DELAY_SLOT_CLEARME (1 << 3) > +/* The dynamic value of the DELAY_SLOT_TRUE flag determines whether the jump > + * after the delay slot should be taken or not. It is calculated from SR_T. > + * > + * It is unclear if it is permitted to modify the SR_T flag in a delay slot. > + * The use of DELAY_SLOT_TRUE flag makes us accept such SR_T modification. > + */ Nesting a 'tst' in a delay slot is certainly valid, and GCC correctly treats it as a slottable instruction. If you're in doubt as to whether an opcode can be placed in a delay slot or not, the machine descriptor is a good way of sorting things out. The only restrictions I know of things that cause changes to PC, most of the system instructions (like trapa and ldtlb), and so on. There are of course cases where an instruction itself is slottable which may perform illegal behaviour via PC modification or so on, and we do have an exception for trapping that sort of abuse. 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 .... This sort of access is not a particularly rare workload. Presumably you'd hit this under system emulation at the very least.