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.
