Re: [Qemu-devel] [PATCH]: sh4 delay slot code update

[Paul Mundt <lethal@linux-sh.org>]

On Thu, Nov 29, 2007 at 02:43:03PM +0900, Magnus Damm wrote:
> On Nov 28, 2007 9:49 PM, Paul Mundt <lethal@linux-sh.org> 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..