This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Reason for not using C28x fast branch

Guru 19935 points

Hello,

The C2000 compiler has an option to disable C28x fast braches.  

In what situations would I want to disable fast branches?

Thanks,
Stephen

  • C2000 "fast branch" instructions are only faster if the code is in RAM (not the usual case).  Most projects had the "disable fast branch" option set by default from the device settings as code is typically run from FLASH or other external memory (in which case the "fast branch" instructions are actually slower).  In the new version of the compiler, we made this the default setting and deprecated the disable fast branch option.  Instead, users will specify when a function is in RAM and we generate the correct branch type for it automatically.  Or the user can specify with a compiler switch that all functions in that translation unit are running out of RAM and we will generate fast branch for them all.

    I don't know what version of the compiler you are using, but if you selected your device in CCS, you probably already have fast branch disabled.  Otherwise, you should do so unless your code is running from RAM.

  • Hello Anna,

    Thanks for the info.  I am using v6.2.11.  It's been around for a quite a while, so that's why I am using it.

    The TMS320C28x CPU and Instruction Set Reference Guide ("http://www.ti.com/lit/ug/spru430f/spru430f.pdf") describes the following about the BF instruction:

    Note: The branch fast (BF) instruction takes advantage of dual prefetch queue on the C28x core that reduces the cycles for a taken branch from 7 to 4:

    It doesn't say anything about the fast branch being faster in RAM than in FLASH.

    Stephen 

  • Hello Anna,

    I checked your post as being the answer, but I would still like to know where I can find the answer.

    Thanks,

    Stephen

  • I have asked the Business Unit to reply to this and post a link to the official collateral, as it is their documentation, not ours.

  • Hi Stephen,

    In memory with waitstates the fast branch (SBF/BF) are slower because the instructions dual fetch at both possible destinations. So basically it is fetching from two different locations each one being impacted by waitstates. In zero wait memory (RAM) SBF/BF are faster.

    I've looked through the documentation, and I agree it is not documented as it should be. I will feed this back to the team for correction.

    Regards
    Lori