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

[Rob Landley]

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".

I'm aware this could impact backwards compatibility with legacy sh2
code. What legacy sh2 binaries are out there that we really care about?
(I'm aware there was a windows CE port to sh2, but I'm not sure that
counts.)

Yes, we _can_ have perfect bug for bug compatibility with legacy
implementations, and we have in fact mostly already achieved that
(modulo this sort of thing). My question is what behavior do we WANT?

(We have the option of giving the build configuration variables for
LEGACY_SH2 and LEGACY_SH3 and such, but having the default j-core
behavior be consistent across j2/j3/j4.)

Speaking of which, we've already got some deviations (cmpxchg and
backported barrel shift), and should have our own brand new architecture
documentation PDFs. There's a goal of having the build generate some of
this stuff but it seems to be more todo items than reality so far, and
there's a lot of descriptive text that just plain needs to be written.
(And translated to/from Japanese, because we should have master versions
of this doc in both languages.)

Rob