[sdiy] DSPIC branches GOTOs etc,

[Scott Gravenhorst]

"Richie Burnett" <rburnett at richieburnett.co.uk> wrote:
 >Thinking about this some more, since GOTO instructions take up two
 >consecutive program memory locations, then this code snippet shouldn't
 >work...
 >
 >dma_wait:
 >BTSS    IFS0,#DMA1IF    ; Check DMA1 transfer complete flag and skip
 >                          next instruction if it is set
 >GOTO    dma_wait        ; Loop back and wait until DMA transfer is
 >                          complete
 >if flag is still clear
 ><code here to deal with DMA data>
 >
 >The BTSS or BTSC followed by GOTO appears throughout my code and works
 >fine, even though the bit-test instruction only skips *one* program
 >memory location if the tested condition is true.  The only reason it
 >must work is because the second word of the GOTO instruction (the
 >address) is executed as a NOP.  I guess I should go through my program
 >changing all the GOTOs that follow BTSS or BTSC with BRA instructions
 >instead, just in case Microchip alter this behaviour in future!?
 >
 >It's also interesting to note that a CALL instruction to an address
 >label is also coded as two words of program memory.  So using BTSS or
 >BTSC to conditionally jump over a subroutine CALL would also appear to
 >be on shaky ground!

I think it's also faster to use a BRA because when the BTSS jumps over 
the next instruction, it starts by executing a real work instruction, 
not a word that opcodes as a NOP and _then_ executes the real work 
instruction.  And if it matters, each GOTO you can replace with a BRA is 
one less used flash byte (when that matters).  There is also (at least 
with dsPIC33F) the RCALL instruction that can be used in the same way as 
BRA since it's a 1 word instruction regardless of addressing mode.

Since there is no RGOTO instruction, one could make a macro RGOTO that 
translates to a BRA - just to make infinite loop ends obvious (which is 
why I like to use GOTO).

-- ScottG