[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH]: sh4 delay slot code update
From: |
Paul Mundt |
Subject: |
Re: [Qemu-devel] [PATCH]: sh4 delay slot code update |
Date: |
Thu, 29 Nov 2007 14:55:34 +0900 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
On Thu, Nov 29, 2007 at 02:43:03PM +0900, Magnus Damm wrote:
> On Nov 28, 2007 9:49 PM, Paul Mundt <address@hidden> 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..