[sdiy] DSPIC branches GOTOs etc,

[Richie Burnett]

Some good suggestions there Scott and Tom.  Thanks.  I've gone through my 
code and replaced all GOTOs with BRA and it still assembles and runs fine, 
but is a few words shorter in program memory.

I'm always keen to squeeze out every last instruction cycle of something 
like an oscillator algorithm too, because once you multiply the number of 
cycles by the number of oscillators used for one synth voice, then by the 
number of voices in the synth, then by the oversampling ratio, it can end up 
being a very significant number of instruction cycles.  It could easily make 
a difference in terms of the number of voices a particular DSP could 
synthesise simultaneously.

-Richie,



-----Original Message----- 
From: Tom Wiltshire
Sent: Thursday, February 25, 2016 11:39 PM
To: Scott Gravenhorst
Cc: synth-diy at dropmix.xs4all.nl
Subject: Re: [sdiy] DSPIC branches GOTOs etc,


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

_______________________________________________
Synth-diy mailing list
Synth-diy at dropmix.xs4all.nl
http://dropmix.xs4all.nl/mailman/listinfo/synth-diy


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7442 / Virus Database: 4537/11698 - Release Date: 02/26/16