• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 5139 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Jump table for switch statement

David Boles
Intellectual 850 points

Hi,

I was wondering what criterion the compiler uses to generate the jump table for switch statements in the .switch section?  Is this decision based on an efficiency cross-over point of just a number of "case"s?

  • 0
    TI__Guru**** 239445 points

    Two factors are considered.  One is the number of cases.  The other is how close together are the case values.  The closer they are, the more likely a jump table is used.  Because for every value in the range of case values that is not present, you need an entry in the table which branches to the default.  A jump table with lots of entries to the default wastes memory.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Genius 4056 points

    Is there a way to force jump tables for switch statements > x elements or for an optimization level >= O ? (C2000)?

    We are using statemachines and would like to get nearly the same execution time for every state.

    Regards,

    Stephan

  • 0 in reply to StephanS
    TI__Guru* 84225 points
    I'm sorry, there is no user control for the switch table optimization.
  • 0 in reply to Archaeologist
    Genius 4056 points
    Ok, thanks for the info anyways.
    Maybe a feature request for a future release?
  • 0 in reply to StephanS
    TI__Guru**** 239445 points

    Unfortunately, such a request is not common among our customers.  That being the case, it is unlikely this feature will be implemented.

    Thanks and regards,

    -George

  • 0 in reply to StephanS
    Expert 2215 points

    Hi, Stephan.

    I have the same need occasionally, and have used compilers in the past that had #pragma hint type lines where you could tell the compiler which of something like 6 different algorithms to use for a switch statement.  A jump table was one of them.

    However, being that you and I both are going to have to deal with our cases, I thought I'd mention this in case you weren't already planning to proceed down this route:

    If you are familiar with building a jump table in assembly language, you can do it in C as well:  Create an array of jump pointers by populating it with C labels.  If possible, arrange your state machine cases to be numerically in sequence (0-N cases, with as few skips as possible).  Populate your array, and then at the top of your manually-implemented jump table, issue a C 'goto' using the array element indexed by your case.  It will be close to assembly language efficiency, and more importantly, from your primary need, it will give you a consistent time-to-start-execution for each case.  Just not quite as easy as 'switch' syntax.

    Hope this helps.

    --Vic

  • 0 in reply to George Mock
    Expert 2215 points
    Hi, George!

    Well, I suggested an alternative to Stephan, but for the record, please register THIS message as ANOTHER official request for switch options (e.g. #pragma hint (?) for switch algorithm) -- one of which to be a jump table when the cases as array indexes are efficient. :-)

    Hope things are going superlatively well.

    Kind regards,
    Vic Wheeler
  • 0 in reply to Victor Wheeler61
    Genius 4056 points

    Hi Vic,

    thanks for providing your solution. This is an elegant solution for static/fixed switch tables.

    Unfortunately, we have an additional drawback: We have automatic generated statemachines from a statemachine tool.

    So your solution does not work for us - we would have to manually adjust the switch tables on every automatic generated statemachine change.

    So I can only second your request for switch/jump table options.

    Stephan

  • 0 in reply to Victor Wheeler61
    TI__Guru* 84225 points
    Vic, if I understand what you are proposing, this relies upon the GCC "computed goto" feature, which is not supported by the TI compiler. Specifically, you can't take the address of a label.
  • 0 in reply to Archaeologist
    Expert 2215 points

    Hi, Archaeologist.

    Wow, that is important! Well, then please allow me to re-affirm my request for a jump-table algorithm option for 'switch' statements. :-)

    When there are only 3-5 cases in a switch statement, it's not going to play a big role, but when there are state machines that have 50 to several hundred options, this is a HUGE, HUGE efficiency point.  In the world where every design decision is time-critical, for example, processing incoming signals for high-speed automotive and racing applications -- which is where I live -- this can be a make-break point in the workability of an algorithm!  Please urge the team to consider this.

    Kind regards,
    Vic

  • 0 in reply to Victor Wheeler61
    TI__Guru* 84225 points
    Very well. I have submitted enhancement request SDSCM00052764. This request will be considered by the enhancement committee. This is not a guarantee of acceptance or priority.
  • 0 in reply to Archaeologist
    TI__Guru* 84225 points
    By the way, do you truly need "nearly the same execution time for every state" or do you really want the fastest possible code for non-default cases?
  • 0 in reply to Archaeologist
    Expert 2215 points
    Hi, Archaeologist. That's all I can ask for. :-) Thank you!
  • 0 in reply to Archaeologist
    Genius 4056 points

    Hmm, of course both...:-)


    From an execution time analysis perspective, "nearly the same execution time for every state" is better because then you do not have to track the execution time of every state for a worst-case timing analysis.