CCE is now out of beta and at release version 1.0. I have re-examined
and retested code example 6.5 in section 6.8.2.1 of "MSP430 Optimizing
C/C++ Compiler User's Guide (SLAU132)" to see if works as is or
still
needs to be modified to produce proper jump table code as occurred in
the beta edition. Other than with minor irrelevant editing, the code
example in the user's guide produces correct jump table code.

A complete example incorporating example 6.5 is provided below.

I have amended comments in the InterMSP430CompilerPortability.h file.
While it may be possible to relax some of the conditions I indicated
for the portability macros, I have not examined this.

It is probably helpful to the group to discuss what a jump table is.
Both Paul Curtis and Al have made mistakes. Paul Curtis gave an
example of disassembly code produced from CrossWorks which was
conditional code that jumped. It was not unconditional jump table code
and it is inaccurate to state or imply it was it was jump table code.
Al confused a jump table with a table that returns literal values.
Although there may be some web links that support Al's views, they are
incorrect. It is like stating a truck can carry a passenger. While
true it is very far from the complete picture of what a truck is for
and what it can do.

First the concept of a jump table is well understood in computer
science. Below are three web site links from computer science oriented
sites where jump tables are mentioned.
http://courses.ece.uiuc.edu/ece398/ssl/mps/mps.html
http://condor.depaul.edu/~slytinen/373/l5.html
http://www.cs.helsinki.fi/u/kuuppelo/tito/k2005/laskuharj/exercise4.ht
ml

In computer science two ways of branching are considered: using
conditionals or using jump tables. In standard C conditional branching
is achieved with if/else statements and with switch statements. While
a switch statement is written as if it is jump code, it always appears
to be implemented as conditional if/else type code. In C jump table
branching can be achieved with tables of function pointers.
Conditional branching can be fast if there are few cases and slow if
there are many cases. Jump table branching in C looks up the function
address of the target in a table, avoids conditionals and is practical
where the integer constants can be kept within a practical range. To
quote from one site "Advantage of Jump Table: Can do k-way branch in
O(1) operations".

The C standard makes it difficult to make a switch statement produce
jump table code. IAR and CCE get around this by allowing a variant of
the switch statement that produces jump code.

The term 'jump table' appears three times in the 'MSP430x1xx
Family
User's Guide', which is the definitive source of information common to
this MSP430 series. In each place where the term 'jump table' appears
there is an example of jump table code without conditionals. The
equivalent term 'calculated branching' appears twice in the same
manual. It is clear, that Texas Instruments expects readers to be
familiar with or understand the term 'jump table' since they feel no
need to define it. However even if a reader is not familiar with the
term it is not difficult to work out what is meant from examination of
the code.

These comments have been included in the amended file
InterMSP430CompilerPortability.h available in the file section,
although I have not included comments about Paul and Al. In addition I
have added port interrupts macros and made it clear the watchdog 
interrupt applies when the watchdog is operating in interval timer 
mode rather than watchdog mode.

John Heenan

Example 6.5 from "MSP430 Optimizing C/C++ Compiler User's Guide
(SLAU132)" incorporated into a full example

#include  <msp430x16x.h>

unsigned int state=0;  //not initilised to 0 by default

__interrupt void Timer_B1(void);
TIMERB1_ISR(Timer_B1)
__interrupt void Timer_B1 (void)
{
  switch( TBIV )
  {
    case 0: break; // Do nothing
    case 2: TBCCR1 += 255;   //Module 1
      state +=1;
      break;
    case 4: TBCCR0 = 254; //255?1;  Module 2
      TBCCR1 =  159;      //255?96;
      state  0;
      break;
    case 6:
    case 8:
    case 10:
    case 12:
    case 14:
    default: _never_executed();
  }
}

void main()
{

  WDTCTL = WDTPW + WDTHOLD;  // Stop WDT
//P1DIR |= 0x01;             // P1.0 output
  TBCCTL1 = CCIE;            // Module 1, vector 2 interrupt enabled
  TBCCTL2 = CCIE;            // Module 2, vector 4 interrupt enabled
  TBCCR1 = 50000;
  TBCCR2 = 50000;
  TBCTL = TBSSEL_2 + MC_2 + TBCLR;       // SMCLK, contmode
  _bis_SR_register(LPM0_bits + GIE);    // Enter LPM0 w/ interrupt
}

Give it a rest.

Regards
-Bill Knight
R O SoftWare &
http://www.theARMPatch.com



On Thu, 12 May 2005 20:11:34 -0000, John Heenan wrote:

>CCE is now out of beta and at release version 1.0.
I have re-examined
>and retested code example 6.5 in section 6.8.2.1 of "MSP430 Optimizing
>C/C++ Compiler User's Guide (SLAU132)" to see if works as is
or still
>needs to be modified to produce proper jump table code as occurred in
>the beta edition. Other than with minor irrelevant editing, the code
>example in the user's guide produces correct jump table code.

>A complete example incorporating example 6.5 is
provided below.

>I have amended comments in the
InterMSP430CompilerPortability.h file.
>While it may be possible to relax some of the conditions I indicated
>for the portability macros, I have not examined this.

>It is probably helpful to the group to discuss what
a jump table is.
>Both Paul Curtis and Al have made mistakes. Paul Curtis gave an
>example of disassembly code produced from CrossWorks which was
>conditional code that jumped. It was not unconditional jump table code
>and it is inaccurate to state or imply it was it was jump table code.
>Al confused a jump table with a table that returns literal values.
>Although there may be some web links that support Al's views, they are
>incorrect. It is like stating a truck can carry a passenger. While
>true it is very far from the complete picture of what a truck is for
>and what it can do.

>First the concept of a jump table is well
understood in computer
>science. Below are three web site links from computer science oriented
>sites where jump tables are mentioned.
>http://courses.ece.uiuc.edu/ece398/ssl/mps/mps.html
>http://condor.depaul.edu/~slytinen/373/l5.html
>http://www.cs.helsinki.fi/u/kuuppelo/tito/k2005/laskuharj/exercise4.ht
>ml

>In computer science two ways of branching are
considered: using
>conditionals or using jump tables. In standard C conditional branching
>is achieved with if/else statements and with switch statements. While
>a switch statement is written as if it is jump code, it always appears
>to be implemented as conditional if/else type code. In C jump table
>branching can be achieved with tables of function pointers.
>Conditional branching can be fast if there are few cases and slow if
>there are many cases. Jump table branching in C looks up the function
>address of the target in a table, avoids conditionals and is practical
>where the integer constants can be kept within a practical range. To
>quote from one site "Advantage of Jump Table: Can do k-way branch in
>O(1) operations".

>The C standard makes it difficult to make a switch
statement produce
>jump table code. IAR and CCE get around this by allowing a variant of
>the switch statement that produces jump code.

>The term 'jump table' appears three times
in the 'MSP430x1xx Family
>User's Guide', which is the definitive source of information
common to
>this MSP430 series. In each place where the term 'jump table'
appears
>there is an example of jump table code without conditionals. The
>equivalent term 'calculated branching' appears twice in the same
>manual. It is clear, that Texas Instruments expects readers to be
>familiar with or understand the term 'jump table' since they feel
no
>need to define it. However even if a reader is not familiar with the
>term it is not difficult to work out what is meant from examination of
>the code.

>These comments have been included in the amended
file
>InterMSP430CompilerPortability.h available in the file section,
>although I have not included comments about Paul and Al. In addition I
>have added port interrupts macros and made it clear the watchdog 
>interrupt applies when the watchdog is operating in interval timer 
>mode rather than watchdog mode.

>John Heenan

>Example 6.5 from "MSP430 Optimizing C/C++
Compiler User's Guide
>(SLAU132)" incorporated into a full example

>#include  <msp430x16x.h>

>unsigned int state=0;  //not initilised to 0 by
default

>__interrupt void Timer_B1(void);
>TIMERB1_ISR(Timer_B1)
>__interrupt void Timer_B1 (void)
>{
>  switch( TBIV )
>  {
>    case 0: break; // Do nothing
>    case 2: TBCCR1 += 255;   //Module 1
>      state +=1;
>      break;
>    case 4: TBCCR0 = 254; //255?1;  Module 2
>      TBCCR1 =  159;      //255?96;
>      state  0;
>      break;
>    case 6:
>    case 8:
>    case 10:
>    case 12:
>    case 14:
>    default: _never_executed();
>  }
>}

>void main()
>{

>  WDTCTL = WDTPW + WDTHOLD;  // Stop WDT
>//P1DIR |= 0x01;             // P1.0 output
>  TBCCTL1 = CCIE;            // Module 1, vector 2 interrupt enabled
>  TBCCTL2 = CCIE;            // Module 2, vector 4 interrupt enabled
>  TBCCR1 = 50000;
>  TBCCR2 = 50000;
>  TBCTL = TBSSEL_2 + MC_2 + TBCLR;       // SMCLK, contmode
>  _bis_SR_register(LPM0_bits + GIE);    // Enter LPM0 w/ interrupt
>}





>.

> 
>Yahoo! Groups Links



> 

John, 

> In computer science two ways of branching are
considered: 
> using conditionals or using jump tables. In standard C 
> conditional branching is achieved with if/else statements and 
> with switch statements. While a switch statement is written 
> as if it is jump code, it always appears to be implemented as 
> conditional if/else type code. In C jump table branching can 
> be achieved with tables of function pointers.
> Conditional branching can be fast if there are few cases and 
> slow if there are many cases. Jump table branching in C looks 
> up the function address of the target in a table, avoids 
> conditionals and is practical where the integer constants can 
> be kept within a practical range. To quote from one site 
> "Advantage of Jump Table: Can do k-way branch in
> O(1) operations".

Please explain why my originally-presented code is not O(1)?

Here is a hint: its time complexity is indeed O(1).

Thanks,

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and (soon) MAXQ processors

Resubmit your example with say 10, 20 and 30 cases tested for with 
disassembly. Interested users can see how your code will bloat out 
with a statistical mean order of operaton of half the cases tested 
for, provided each case has an equal chance of being tested for. If 
your code produced true jump table code then the order of operation 
would remain as 1. 

Hint: no one is interested in testing your code for trivially small 
number of cases.

You are flogging a dead horse. CCE and IAR would trash CrossWorks in 
a benchmark test with increasing cases tested for, unless you expect 
users to use tables of function pointers.

John Heenan


--- In msp430@msp4..., "Paul Curtis" <plc@r...> wrote:
> John, 
> 
> > In computer science two ways of branching are considered: 
> > using conditionals or using jump tables. In standard C 
> > conditional branching is achieved with if/else statements and 
> > with switch statements. While a switch statement is written 
> > as if it is jump code, it always appears to be implemented as 
> > conditional if/else type code. In C jump table branching can 
> > be achieved with tables of function pointers.
> > Conditional branching can be fast if there are few cases and 
> > slow if there are many cases. Jump table branching in C looks 
> > up the function address of the target in a table, avoids 
> > conditionals and is practical where the integer constants can 
> > be kept within a practical range. To quote from one site 
> > "Advantage of Jump Table: Can do k-way branch in
> > O(1) operations".
> 
> Please explain why my originally-presented code is not O(1)?
> 
> Here is a hint: its time complexity is indeed O(1).
> 
> Thanks,
> 
> --
> Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
> CrossWorks for MSP430, ARM, AVR and (soon) MAXQ processors

John...
I am sure that I am not the only one, but pointers to functions are perhaps
the most powerful
thing ever devised. I do not know how I would code without them. Especially
when they provide
a shortcut around the limitations of the 4Kbyte Start Kick :):):)

Alex



----- Original Message ----- 
From: "John Heenan" <l10@l10@...>
To: <msp430@msp4...>
Sent: Friday, May 13, 2005 6:03 AM
Subject: [msp430] Re: Comments on jump tables and compiler portability file
update with release of CCE


> Resubmit your example with say 10, 20 and 30 cases
tested for with
> disassembly. Interested users can see how your code will bloat out
> with a statistical mean order of operaton of half the cases tested
> for, provided each case has an equal chance of being tested for. If
> your code produced true jump table code then the order of operation
> would remain as 1.
>
> Hint: no one is interested in testing your code for trivially small
> number of cases.
>
> You are flogging a dead horse. CCE and IAR would trash CrossWorks in
> a benchmark test with increasing cases tested for, unless you expect
> users to use tables of function pointers.
>
> John Heenan
>
>
> --- In msp430@msp4..., "Paul Curtis" <plc@r...> wrote:
> > John,
> >
> > > In computer science two ways of branching are considered:
> > > using conditionals or using jump tables. In standard C
> > > conditional branching is achieved with if/else statements and
> > > with switch statements. While a switch statement is written
> > > as if it is jump code, it always appears to be implemented as
> > > conditional if/else type code. In C jump table branching can
> > > be achieved with tables of function pointers.
> > > Conditional branching can be fast if there are few cases and
> > > slow if there are many cases. Jump table branching in C looks
> > > up the function address of the target in a table, avoids
> > > conditionals and is practical where the integer constants can
> > > be kept within a practical range. To quote from one site
> > > "Advantage of Jump Table: Can do k-way branch in
> > > O(1) operations".
> >
> > Please explain why my originally-presented code is not O(1)?
> >
> > Here is a hint: its time complexity is indeed O(1).
> >
> > Thanks,
> >
> > --
> > Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
> > CrossWorks for MSP430, ARM, AVR and (soon) MAXQ processors
>
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>

John, 

> Resubmit your example with say 10, 20 and 30 cases
tested for 
> with disassembly. 

Sure.  Attached for 30 cases.

> Interested users can see how your code will 
> bloat out with a statistical mean order of operaton of half 
> the cases tested for, provided each case has an equal chance 
> of being tested for.

Look at the original code I produced below and see that it is O(1) and
the only "bloat" is in the table of destintation.  It doesn't run
in
linear time O(n), it runs in constant time O(1) as the BR is independent
of value.  There is ONE compare which sees whether the value lies
outside the range of the table--take a GOOD look, you obviously need
spectacles.

> If your code produced true jump table 
> code then the order of operation would remain as 1. 

My original code posted below is O(1) and so are cases for 10, 20, and
30 items.  I don't expect you to understand John, but gee, the code is
constant-time because, well, it uses a table of addresses to jump to.

> You are flogging a dead horse. CCE and IAR would
trash 
> CrossWorks in a benchmark test with increasing cases tested 
> for, unless you expect users to use tables of function pointers.

Please, demonstrate how they trash my compiler by example--I'd love to
take them on as I can raise my bar.  You are obviously a TI stooge with
a secret agenda.

My original code, with comments which I present for the hard of
understanding:

int i;

void foo(void)
{
  switch (i)
  {
  case 1: ++i;
  case 2: i += 2;
  case 3: i += 3;
  case 4: i += 4;
  }
}

Generates:

3: void foo(void)

_foo

5: switch (i)

  MOV.W   &_i, R15  ; get i
  SUB.W   #1, R15   ; adjust as no case 0
  CMP.W   #4, R15   ; default required?
  JC @1             ; yep, branch to default case
  ADD.W   R15, R15  ; index into table
  BR @2(R15)        ; jump
@2
  DW @3
  DW @4
  DW @5
  DW @6

Of course, 30 items is a simple extension (I used cases 0 through 30
here):

     5:   switch (i)

    MOV.W   &_i, R15 ; started with case 0: anyway
    CMP.W   #31, R15 ; more than 0-30 cases?
    JC      @1       ; branch to default
    ADD.W   R15, R15 ; index into table
    BR      @2(R15)  ; jump
@2
    DW      @3
    DW      @4
    DW      @5
    DW      @6
    DW      @7
    DW      @8 
    DW      @9
    DW      @10
    DW      @11
    DW      @12
    DW      @13
    DW      @14
    DW      @15
    DW      @16
    DW      @17
    DW      @18
    DW      @19
    DW      @20
    DW      @21
    DW      @22
    DW      @23
    DW      @24
    DW      @25
    DW      @26
    DW      @27
    DW      @28
    DW      @29
    DW      @30
    DW      @31
    DW      @32
    DW      @33

Hi John, Paul, Al et al,

After observing this thread for a while , I found things were getting :
1.    Too silly
2.    At times inaccurate wrt "facts".
3.    Opinion prone, rather than exact.

But first I have a question :

Who is CCE ?
Is that the same company that sold its PIC compiler to Microchip
(which truly was the shittiest compiler I'd ever seen). It may have been
CCS ?
It would be great so I can get my own "facts" on this straight.

Some of the topics discussed are opinion-prone, IMO (if that makes sense) :

> It is probably helpful to the group to discuss
what a jump table is.

I think since this is an MSP430 group, that the term "symbolic addressing
mode"
is much more appropriate.

> Both Paul Curtis and Al have made mistakes. Paul
Curtis gave an
> example of disassembly code produced from CrossWorks which was
> conditional code that jumped. It was not unconditional jump table code
> and it is inaccurate to state or imply it was it was jump table code.

Maybe I wasn't privy enough to the origin of this claim, but I don't
see why jump table code must be "unconditional".
If it were, what would be the point of having a "jumptable" in the
first place ?

This is why I mentioned "symbolic addressing mode".
The "jump" is actually a compound of offsetting into a literal table
(addresses)
and then fetching a label's address, followed by a branch to that address.
All in one instruction.....
I prefer to use "computed branch" instead.

> Al confused a jump table with a table that returns
literal values.

If it applies to the switch by using a computed branch, then that'e
_exactly_ what the
table does, the literal is the address of the appropriate CASE statement.
Perhaps it would be better to use "Look Up Table" (LUT) , then it is
generic.

Consider this switch :

i = 0 ;
switch ( num )
    {
    case 0 : i++ ;
    case 1 : i++ ;
    case 2 : i++ ;
    case 3 : i++ ;
    case 4 : i++ ;
    }

The higher the value of <num> is, the lower <i> will be.

I used such a switch once in an expression precedence evaluator, but then
replaced it with :

> First the concept of a jump table is well
understood in computer
> science. Below are three web site links from computer science oriented
> sites where jump tables are mentioned.
> http://courses.ece.uiuc.edu/ece398/ssl/mps/mps.html
> http://condor.depaul.edu/~slytinen/373/l5.html
> http://www.cs.helsinki.fi/u/kuuppelo/tito/k2005/laskuharj/exercise4.ht
> ml

Thanks John, I will check these out myself.

> In computer science two ways of branching are
considered: using
> conditionals or using jump tables. In standard C conditional branching
> is achieved with if/else statements and with switch statements. While
> a switch statement is written as if it is jump code, it always appears
> to be implemented as conditional if/else type code. 

Not true.
Most MSP430 C compilers will pick what's most efficient according to the
settings (speed vs. size). (and I doubt any ASM programmer will beat it).

> In C jump table branching can be achieved with
tables of function pointers.

Refer my switch example below, no function pointer is needed (and almost never
is for switch statements).

> Conditional branching can be fast if there are few
cases and slow if
> there are many cases. 

On a crappy compiler only....

> Jump table branching in C looks up the function
> address of the target in a table, avoids conditionals and is practical
> where the integer constants can be kept within a practical range. To
> quote from one site "Advantage of Jump Table: Can do k-way branch in
> O(1) operations".
> 
> The C standard makes it difficult to make a switch statement produce
> jump table code. IAR and CCE get around this by allowing a variant of
> the switch statement that produces jump code.

Proviso we are talking about switch by computed branch, you are ill-informed
here John.
The FIRST to implement the option of forcing a switch statement to only use
a computed branch was Hitech-C's HT-430 , way before IAR.
(This is approximately 4 yrs ago, the CCE you refer to didn't even exist
then, and
CrossWorks shortly after started its internal Beta testing)
I had suggested such option to IAR, and presume this is what you are referring
to,
IOW IAR at some stage implemented it as well (I discussed this with Anders a
while ago,
but I didn't use IAR anymore since).
For all I know Hitech-C HT-430 still is the only compiler that can do that.
Introducing a "variant" to the switch statement seems a bad idea to
me.
Can you describe what the variant is, John ?

NOTE to other readers :
If you want to execute your switch statements the fastest, it is best to use
CASE
values that are enumerated to fairly close consecutive values.
This ensures a computed branch rather than if/else/if/else decision tree style
ASM.
There have been occasions where I had say 100 or so CASE statements, all fairly
consecutive,
but there might be a gap of say 10 integer values between 2 cases.
In this case the compiler will most likely resort to decision tree switches.
The option I refer to allows you to force the compiler to use a computed branch.
You might end up with a jump table that has, say 15-20 superfluous literals in
the branch
LUT (Look Up Table), but it STILL is :
1.    Much faster than the decision tree
2.    Much less code space than the decision tree.
The only downer of course is that if you leave a gap of decimal integer - say -
2,000,
that you will end up with 2,000 address entries in the LUT !!
I don;t see that as a problem, as the use of the option (I think) implies a C
writer that is concerned
with the quality of its generated ASM, thus wull not allow such event.

 
> The term 'jump table' appears three
times in the 'MSP430x1xx Family
> User's Guide', which is the definitive source of information
common to
> this MSP430 series. In each place where the term 'jump table'
appears
> there is an example of jump table code without conditionals. The
> equivalent term 'calculated branching' appears twice in the same
> manual. 

One has NOTHING to do with the other perse, on MSP430.
Using your truck logic, that like categorically stating :
" I fit in my jacket, and my jacket fits in a small briefcase, therefore I
fit in my small briefcase"

> It is clear, that Texas Instruments expects
readers to be
> familiar with or understand the term 'jump table' since they feel
no
> need to define it. 

TI does not have that obligation because they are are not necessarily the same,
nor are the 2
terms mutually exclusive.
And again, the examples you refer to surely must have been in the chapter that
deals with addressing
modes, in this case symbolic.

> However even if a reader is not familiar with the
> term it is not difficult to work out what is meant from examination of
> the code.

Further, on must define portability :
Portability between compilers on MSP430, or portability of the code between
processors,
or both ?


> Example 6.5 from "MSP430 Optimizing C/C++
Compiler User's Guide
> (SLAU132)" incorporated into a full example

[SNIP]

> __interrupt void Timer_B1 (void)
> {
>   switch( TBIV )
>   {
>     case 0: break; // Do nothing
>     case 2: TBCCR1 += 255;   //Module 1
>       state +=1;
>       break;

When focused on the switch issue, if there are more than say 4 CASE statements,
it would make
a lot more sense to switch like this :

switch( TBIV>>1 )
   {
    case 0: break; // Do nothing
    case 2: TBCCR1 += 255;   //Module 1
    ...

B rgds
Kris De Vos

I am not touching this thread with a 10 foot pole :-) but CCS is the PIC 
compiler company. CCE is the new TI "I want to build a empire" MSP430
C 
compiler. The IDE is Eclipse but the compiler is homegrown, apparently.

At 01:00 AM 5/14/2005, microbit wrote:
>...
>But first I have a question :
>
>Who is CCE ?
>Is that the same company that sold its PIC compiler to Microchip
>(which truly was the shittiest compiler I'd ever seen). It may have
been CCS ?
>It would be great so I can get my own "facts" on this straight.
>...

// richard (This email is for mailing lists. To reach me directly, please 
use richard at imagecraft.com) 

----- Original Message ----- 
From: "microbit" <microbit@micr...>
To: <msp430@msp4...>
Sent: Saturday, May 14, 2005 9:00 AM
Subject: Re: [msp430] Comments on jump tables and compiler portability file 
update with release of CCE


> Hi John, Paul, Al et al,
>
> After observing this thread for a while , I found things were getting :
> 1.    Too silly
> 2.    At times inaccurate wrt "facts".
> 3.    Opinion prone, rather than exact.
>
> But first I have a question :
>
> Who is CCE ?
> Is that the same company that sold its PIC compiler to Microchip
> (which truly was the shittiest compiler I'd ever seen). It may have
been 
> CCS ?
> It would be great so I can get my own "facts" on this straight.

We bought the Microchip compiler where I used to work and found it to be 
unusable. We got the Hi-Tech product which had one or two bugs, but got the 
job done. The C30 compiler for the dsPICs is based on gcc, and therefore 
quite good.

Leon 

Hi John and Paul,
(apostles :-)

> Resubmit your example with say 10, 20 and 30 cases
tested for with 
> disassembly. Interested users can see how your code will bloat out 
> with a statistical mean order of operaton of half the cases tested 
> for, provided each case has an equal chance of being tested for. If 
> your code produced true jump table code then the order of operation 
> would remain as 1. 

Even an ASM programmer would be faced with such if this is the case.

> Hint: no one is interested in testing your code
for trivially small 
> number of cases.

While I readily volunteer to be a die-hard CrossWorks user, I beg to differ
John.
The strength of the heuristics, and the amount of them, for a switch statement
faces the toughtest test with fewer cases, compared to lots of them IMO.

I've been switch-obsessive (heh) on CrossWorks for a couple of years now,
and I can assure you that CrossWorks by now has matured to a pretty high
standard
of "intelligence" in its deployment of switch bodies.
Having written switch code so often where I keep a close eye on the ASM output,
I've seen that CrossWorks will resort to computed branch as best as
possible
(preferred on MSP430 for code size AND speed).
If the lowest value case is >> 0, the whole literal case list will be
"offset" nicely,
and I found that a fine balance has been created when using 150-250 case
statements.
I've had moments where say 12 missing literals in an otherwise consecutive
list will
be "padded" with an address for a jump to the default (if any, ie.
> the highest value of CASE).
But I'd still like to see even bigger padding ranges.
In general one can afford to "shuffle" around on the case values such
that they're guaranteed
to produce a computed branch.

 
> You are flogging a dead horse. CCE and IAR would
trash CrossWorks in 
> a benchmark test with increasing cases tested for, unless you expect 
> users to use tables of function pointers.

I must agree with Paul.
I don't have that CCE compiler, but I'd sure like to see example
generated ASM code 
from it for - say - 
this switch statement :



typedef enum {
              case_1 = 100,
              case_2 = 101,
              case_3 = 102,
              case_4 = 103,
              case_5 = 109,
              case_6 = 110,
              case_6 = 112
                    } case_val_t;


void main (void)
{
case_val_t  benchmark;
unsigned i;

    switch ( benchmark )
        {
        case case_1:    i = 1 ;    break;
        case case_2:    i = 2 ;    break;
        case case_3:    i = 5 ;    break;
        case case_4:    i = 10 ;    break;
        case case_5:    i = 20 ;    break;
        case case_6:    i = 100 ;    break;
        case case_7:    i = 200 ;    break;
        }

}

CrossWorks Test results :
=================code size of entire switch body :    32 words
Execution through entire switch body =>
When valid case of < i > entry value  :  14 cycles
Default values (including < 100)         :  7  cycles

Please provide the ASM output and/or # of cycles/code that CCE needs to do this.

-- Kris














> 
> John Heenan
> 
> 
> --- In msp430@msp4..., "Paul Curtis" <plc@r...> wrote:
> > John, 
> > 
> > > In computer science two ways of branching are considered: 
> > > using conditionals or using jump tables. In standard C 
> > > conditional branching is achieved with if/else statements and 
> > > with switch statements. While a switch statement is written 
> > > as if it is jump code, it always appears to be implemented as 
> > > conditional if/else type code. In C jump table branching can 
> > > be achieved with tables of function pointers.
> > > Conditional branching can be fast if there are few cases and 
> > > slow if there are many cases. Jump table branching in C looks 
> > > up the function address of the target in a table, avoids 
> > > conditionals and is practical where the integer constants can 
> > > be kept within a practical range. To quote from one site 
> > > "Advantage of Jump Table: Can do k-way branch in
> > > O(1) operations".
> > 
> > Please explain why my originally-presented code is not O(1)?
> > 
> > Here is a hint: its time complexity is indeed O(1).
> > 
> > Thanks,
> > 
> > --
> > Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
> > CrossWorks for MSP430, ARM, AVR and (soon) MAXQ processors
> 
> 
> 
> 
> .
> 
> 
> 
> 
> 
> --------
> . 
> 
>