[sdiy] DSPIC branches GOTOs etc,

[Tom Wiltshire]

On 25 Feb 2016, at 23:29, Scott Gravenhorst <music.maker at gte.net> wrote:

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

Scott makes some good points, and I agree.

However, I don't thing the ground is all that shaky. I can't see Microchip deliberately wrecking all their customers legacy code lightly, which is what would be implied by the change you suggest, Richie. The whole point of their way of ignoring certain bytecodes is that you *can* do stuff like this safely. You're not the only one doing it. I'm sure there's an example in my code somewhere.

But still - if you can save an instruction cycle and a word of memory, that's an improvement and you should do it, so I agree with your principle and Scott's evaluation.

Tom