[J-core] Delay slots 2: Electric Boogaloo (Illegal instructions in delay slots)

Rich Felker dalias at libc.org
Thu Jul 21 17:26:43 EDT 2016


On Thu, Jul 21, 2016 at 03:52:50PM -0500, Rob Landley wrote:
> On 07/21/2016 02:21 PM, Rich Felker wrote:
> > Note that in the special case where the branch is not taken, though,
> > there is no need for the emulator to be aware that a branch was even
> > present. Logically the effect is the same as if the untaken branch did
> > not execute its delay slot, but instead jumped to the instruction
> > address immediately after it (i.e. its delay slot). So where the
> > kernel comment reads:
> > 
> > /*
> >  * handle an instruction that does an unaligned memory access
> >  * - have to be careful of branch delay-slot instructions that fault
> >  *  SH3:
> >  *   - if the branch would be taken PC points to the branch
> >  *   - if the branch would not be taken, PC points to delay-slot
> >  *  SH4:
> >  *   - PC always points to delayed branch
> >  * - return 0 if handled, -EFAULT if failed (may not return if in
> >  * kernel)
> >  */
> 
> It would be really, _really_ nice if j-core had consistent behavior
> across j1/j2/j3/j4/j64. The new architecture is still soft enough that
> we could probably make this kind of decision and say "the sh4 semantics
> for branch delay slots are what j2 will do starting with release 3".

In this case I think the niceness is overrated. The SH3 behavior is
slightly easier for kernels to handle because they don't have to
implement processing of conditional branch logic, but the SH4 behavior
was likely more efficient with the SH4's pipeline architecture. I
suspect it would be ideal to leave it unspecified which behavior
occurs; it really should not matter to applications, but could make a
big difference to be ability to have more efficient pipeline designs.

Rich


More information about the J-core mailing list