On Thu, Nov 29, 2007 at 02:43:03PM +0900, Magnus Damm wrote: > On Nov 28, 2007 9:49 PM, Paul Mundt <[EMAIL PROTECTED]> 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..
