{"id":102788,"date":"2019-08-16T07:00:00","date_gmt":"2019-08-16T14:00:00","guid":{"rendered":"http:\/\/devblogs.microsoft.com\/oldnewthing\/?p=102788"},"modified":"2019-09-13T21:44:54","modified_gmt":"2019-09-14T04:44:54","slug":"20190816-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20190816-00\/?p=102788","title":{"rendered":"The SuperH-3, part 10: Control transfer"},"content":{"rendered":"

Yes, we have once again reached the point where we have to talk about branch delay slots. I will defer to the background information I provided when the issue arose in the discussion of the MIPS R4000<\/a>. Basically, the branch delay slot is an instruction that occurs in the instruction stream after a branch. That instruction executes even when the branch is taken. (Of course, if the branch is not taken, the instruction executes normally as well.)<\/p>\n

On the SH-3, the single-instruction branch delay slot is not sufficient to cover for the pipeline bubble created by a branch. Due to the pipeline structure, two instructions have already been fetched by the time the processor determines whether the branch is taken. The first such instruction goes into the branch delay slot, and the second one is converted to a nop<\/code>. So even if you fill the branch delay slot, you still get a one-cycle stall for the discarded instruction. Therefore, you should prefer to structure branches so that they are normally not taken.<\/p>\n

Okay, here we go.<\/p>\n

    BT      label   ; branch if T=1, reach is 256 bytes, squash the delay slot\r\n    BT\/S    label   ; branch if T=1, reach is 256 bytes\r\n\r\n    BF      label   ; branch if T=0, reach is 256 bytes, squash the delay slot\r\n    BF\/S    label   ; branch if T=0, reach is 256 bytes\r\n<\/pre>\n
The branch if true<\/i> and branch if false<\/i> test the T<\/var> flag and branch if it is set (true) or clear (false). This particular branch is interesting because you get to choose whether you want the instruction in the delay slot to execute. Note that you already paid for the delay slot, so choosing not to execute it doesn’t make things run any faster. The processor just converts the instruction to a nop<\/code> and you waste a cycle.\u00b9<\/p>\n
    BRA     label   ; branch always, reach is 4KB\r\n    BRAF    Rn      ; branch to PC + Rn + 4\r\n    JMP     @Rn     ; branch to Rn\r\n\r\n    BSR     label   ; branch always, reach is 4KB, PR = return address\r\n    BSRF    Rn      ; branch to PC + Rn + 4, PR = return address\r\n    JSR     @Rn     ; branch to Rn, PR = return address\r\n\r\n    RTS             ; branch to PR\r\n<\/pre>\n
These instructions perform unconditional branches, either to a specific address within 4KB (branch always<\/i>), to an address relative to the current program counter (branch always far<\/i>), or to an address provided by a register (jump<\/i>). The xSR<\/code> instructions branch to a subroutine and record the return address in the special pr<\/var> register. And of course after you branch to a subroutine, you need a way to get back, hence RTS<\/code> return from subroutine<\/i>.<\/p>\n
The extra +4 in the BRAF<\/code> and BSRF<\/code> are due to pipelining. By the time the processor determines that the branch needs to be taken, the program counter has already moved ahead two instructions.<\/p>\n
The Microsoft compiler doesn’t use the BSR<\/code> instruction because the linker is very likely to put the branch target outside the 4KB reach of the BSR<\/code> instruction.<\/p>\n
The Microsoft compiler uses the BRAF<\/code> instruction in just one specific scenario (which we’ll look at later), and it doesn’t appear to use BSRF<\/code> at all. The BRAF<\/code> and BSRF<\/code> instructions appear to be useful for writing position-independent code.<\/p>\n
Watch out<\/b>: Even though the JMP<\/code> and JSR<\/code> instructions use an @<\/code>, there is no memory access going on. I don’t know why the mnemonic uses an @<\/code>.<\/p>\n
Note that the BT<\/code> and BF<\/code> instructions have a very limited reach. If you need to branch further, you’ll have to use a trick like branching to a branch, or reversing the sense of the test to jump over a branch instruction with greater reach.<\/p>\n
    ; BT toofar\r\n\r\n    ; option 1: branch to a branch (trampoline)\r\n    BT      trampoline\r\n...\r\ntrampoline:\r\n    BRA      toofar+2\r\n    delay_slot_instruction ; move first instruction of toofar here\r\n\r\n    ; option 2: reverse the sense and jump over a branch\r\n\r\n    BF      skip\r\n    BRA     toofar+2\r\n    delay_slot_instruction ; move first instruction of toofar here\r\nskip:\r\n<\/pre>\n
The SH-3 deals with branch delay slots slightly differently from the MIPS R4000. The SH-3 temporarily disables interrupts between the branch instruction and its delay slot, so you cannot get interrupted in the branch delay slot.<\/p>\n
If an exception occurs on the instruction in the branch delay slot, the exception is raised, and assuming the kernel fixes the problem, execution resumes at the branch instruction. This is safe because the branch instructions are all restartable; the only register modification is to pr<\/var>, but none of the xSR<\/code> instructions consume pr<\/var>, so it’s okay to re-execute them; you just set pr<\/var> twice to the same value.<\/p>\n
Some instructions are disallowed in a branch delay slot.<\/p>\n