how to use intrinsic of "_even_in_range()"

Thank you so much for your reply.

I understand effect of this intrinsic. I will try to check created code used intrinsic and not.

Bernhard Weller said:

Basically the compiler is able to generate an efficient jump table, just through adding the switch argument to the instruction pointer.

Normally, a switch/case construct translates into something like this:

switch(a){
  case 1: case 2:
    break;
  case 3:
    break;
  default: ;
}

->

int b = a; // so a is read only once, to avoid side-effects
if(b==1 or b==2){
}
else
if (b==3) {
} else
;

Using the __even_in_range() intrinsic, the compiler creates something like this

ADD a, PC    ; adds 0,2,4,6... to PC, which effectively is a 'jump' onto one of the following jumps
JMP case0
JMP case2
JMP case4
...
case0: [code]
case2: [code]
case4: [code]
...

no matter which case is hit, it only takes 5 MCLK cycles to start executing the associated code, while the 'standard' code is a chain of comparisons and conditional jumps, the last case being the slowest one executed. So it's faster and shorter to use this intrinsic. And the preferred code for ISRs for modules that provide a vector register (e.g. USCI, timers, ADCs and on newer MSPs even the ports)

Bernhard Weller said:

it's the _never_executed() intrinsic.

Jens-Michael Gross said:

It's impact is actually the same as not providing the default case at all, which omits the final else, but triggers a warning on newer compilers.

If I'm reading you correctly you are implying that this has no effect on other optimizations - such as generating a jump table. From my readings of the C/C++ code generation tools manual (see section 6.7.3, page 123) this would be incorrect and also the answer I got in the compiler forum suggests that these two intrinsics have the same effect used on a vector generator although _never_executed() is more general and can be used in general switch statements.

Well, telling that the default case is never used does not imply that there aren't any cases from 0 to 65535. Including non-even ones. This makes  a jumptable of the add-to-PC type impossible.
By reading the manual you pointed to, it indeed looks like the compiler tries to make sort of a jumptable liek with the __even_in_range intrinsic. However, the manual doesn't say that a case 1: is invalid when using the _never_executed().

So I was talking about the case described in 6.7.3.2 of the manual.
The benefit is that after testing all but one case, you knowdon't need to test for the last one as ther eis no other option (as to the coder's promise). And if, then the code runs wild, introducing a backdoor for bugs.

Maybe the compiler analyzes the cases and decides whether a jumptable is possible (only even cases) and useful (based on the size required for a complete table compared to individual compares). Or sees that the parameter is an IV register (since it can be resolved at compiletime to a low address)

Indeed, an __even_in:range() is slower and bigger than a traditional switch when you only need one specific case or two. Or only a few out of a larger number of possible cases.
But when you say there is no default case and you only use a few of all possible cases...
This is probably why the example defines all cases, most just with a break. More to type then. With __even_in_range(9 you define only the cases you need and leave the rest to the default, and the jumptable will contain entries to the default code (or to the end of the switch if ther ei sno default code) for all cases you didn't define in the range.

Really, I don't know why this new intrinsic had to be introduced. There are more important things than that to implement (such as seamless support for >64k and large data model, and 64 bit variables. All of which are still not as good as they could be.

Jens-Michael Gross said:

Really, I don't know why this new intrinsic had to be introduced.

George said that _never_executed() was supported a quite long time before _even_in_range() - though I don't know if IAR implemented the _even_in_range() before TI implemented _never_executed(). But well that's not a really important matter.

You are of course right about the possible backdoor for bugs - but you have that possibility with _even_in_range() as well, if it's not even or in range something bad will happen as well.

I guess I have to try out both intrinsics and see for myself what assembly code is generated. 

Jens-Michael Gross said:

it's the _never_executed() intrinsic.

It's impact is actually the same as not providing the default case at all, which omits the final else, but triggers a warning on newer compilers. So it just suppresses the warning (allows to be compliant to newer C standard which require the default)[/quote]

It's been a few  years since I kept close track of C standardization efforts, but this surprised me: can you provide a reference to what version of C started (or will start) requiring a default clause in a switch statement?  I thought compilers just warned about missing cases/defaults to help expose coding errors.

Bernhard Weller said:

I guess I have to try out both intrinsics and see for myself what assembly code is generated. 

I must be doing something wrong - it won't create a simple addition, the code I tried (based on a TI code example):

#include "msp430f5418A.h"

volatile int a = 0;

void main(void)
{
  WDTCTL = WDTPW + WDTHOLD;                 // Stop WDT
  TA1CTL = TASSEL_1 + MC_2 + TACLR + TAIE;  // ACLK, contmode, clear TAR
                                            // enable interrupt

  __bis_SR_register(LPM3_bits + GIE);       // Enter LPM3, enable interrupts
  __no_operation();                         // For debugger
}

// Timer_A3 Interrupt Vector (TAIV) handler
#pragma vector=TIMER1_A1_VECTOR
__interrupt void TIMER1_A1_ISR(void)
{
  switch(__even_in_range(TA1IV,14))
  {
     case  0: a=0;                
     break;                          
     case  2: a=1;                 
     break;                        
     case  4: a=2;                 
     break;                         
     case  6: a=3;                
     break;                         
     case  8: a=4;                
     break;                        
     case 10: a=5;                
     break;                        
     case 12: a=6;                
     break;                        
     case 14: a=7;                 
     break;
     default:               
     break;
  }
}

I've turned on optimizations to level 4, tried both optimization for speed or for size. I haven't selected any of the advanced optimization options (I can't see how they would influence this optimization).

The generated assembly is quite long. I've attached the ISR part of it as separate text file:

PUSHM.A   #1,r15                ; [] 
        MOV.W     &TA1IV+0,r15          ; [] |19| 
        TST.W     r15                   ; [] |19| 
        JEQ       $C$L7                 ; [] |19| 
                                          ; [] |19| 
;* --------------------------------------------------------------------------*
        SUB.W     #2,r15                ; [] |19| 
        JEQ       $C$L6                 ; [] |19| 
                                          ; [] |19| 
;* --------------------------------------------------------------------------*
        SUB.W     #2,r15                ; [] |19| 
        JEQ       $C$L5                 ; [] |19| 
                                          ; [] |19| 
;* --------------------------------------------------------------------------*
        SUB.W     #2,r15                ; [] |19| 
        JEQ       $C$L4                 ; [] |19| 
                                          ; [] |19| 
;* --------------------------------------------------------------------------*
        SUB.W     #2,r15                ; [] |19| 
        JEQ       $C$L3                 ; [] |19| 
                                          ; [] |19| 
;* --------------------------------------------------------------------------*
        SUB.W     #2,r15                ; [] |19| 
        JEQ       $C$L2                 ; [] |19| 
                                          ; [] |19| 
;* --------------------------------------------------------------------------*
        SUB.W     #2,r15                ; [] |19| 
        JEQ       $C$L1                 ; [] |19| 
                                          ; [] |19| 
;* --------------------------------------------------------------------------*
        SUB.W     #2,r15                ; [] |19| 
        JNE       $C$L8                 ; [] |19| 
                                          ; [] |19| 
;* --------------------------------------------------------------------------*
        MOV.W     #7,&a+0               ; [] |35| 
        JMP       $C$L8                 ; [] |36| 
                                          ; [] |36| 
;* --------------------------------------------------------------------------*
$C$L1:    
        MOV.W     #6,&a+0               ; [] |33| 
        JMP       $C$L8                 ; [] |34| 
                                          ; [] |34| 
;* --------------------------------------------------------------------------*
$C$L2:    
        MOV.W     #5,&a+0               ; [] |31| 
        JMP       $C$L8                 ; [] |32| 
                                          ; [] |32| 
;* --------------------------------------------------------------------------*
$C$L3:    
        MOV.W     #4,&a+0               ; [] |29| 
        JMP       $C$L8                 ; [] |30| 
                                          ; [] |30| 
;* --------------------------------------------------------------------------*
$C$L4:    
        MOV.W     #3,&a+0               ; [] |27| 
        JMP       $C$L8                 ; [] |28| 
                                          ; [] |28| 
;* --------------------------------------------------------------------------*
$C$L5:    
        MOV.W     #2,&a+0               ; [] |25| 
        JMP       $C$L8                 ; [] |26| 
                                          ; [] |26| 
;* --------------------------------------------------------------------------*
$C$L6:    
        MOV.W     #1,&a+0               ; [] |23| 
        JMP       $C$L8                 ; [] |24| 
                                          ; [] |24| 
;* --------------------------------------------------------------------------*
$C$L7:    
        MOV.W     #0,&a+0               ; [] |21| 
;* --------------------------------------------------------------------------*
$C$L8:    
        POPM.A    #1,r15                ; [] 

What it does is: take TA1IV and put it to R15, compare it, jump, decrease R15, compare it, jump etc. That's not what I expected.

On second thought - maybe the volatile variable prevents the compiler from doing it's optimization right, so I've changed it to toggling pins of P1OUT, with the same result. _never_executed() didn't work as well, only difference was (like expected from the name) that the default case was missing.

Okay P1OUT is also volatile, so third try: instead of using volatile "a", use a static "a" inside the ISR - same result.

Fourth try: just use a normal int "a" - but well then the complete code is optimized away because it's useless. Well saw that coming, assign the value of "a" after the switch to P1OUT. And I'm back to square zero with the whole cmp-jmp party again.

So is my expectation wrong? I was thinking of something like  Jens pointed out:

Jens-Michael Gross said:

ADD a, PC ; adds 0,2,4,6... to PC, which effectively is a 'jump' onto one of the following jumps
JMP case0
JMP case2
JMP case4
...
case0: [code]
case2: [code]
case4: [code]
...

Also the description in the compiler manual indicates that something like this should be created.

What am I doing wrong? 

Bernhard Weller said:

I was thinking of something like  Jens pointed out:
[...]
Also the description in the compiler manual indicates that something like this should be created.

What am I doing wrong?

The code is 16 bytes longer and definitely much slower than what the intrinsic should normally (?) provide.

I don't use CCS, and I did this coding manually in MSPGCC3 inline assembly where appropriate.

Peter Bigot said:

can you provide a reference to what version of C started (or will start) requiring a default clause in a switch statement?

Jens-Michael Gross said:

can you provide a reference to what version of C started (or will start) requiring a default clause in a switch statement?

I remember getting compile errors on GCC when using -pedantic option. So I assumed it was a change in the standard (C99?). I never checked whether it was indeed a standard change or just a GCC interpretation of what 'shouldn't be' in a 'good program' (the GCC folks can sometimes get a bit "nosy"). It's been some 8 years since I used GCC under Linux.[/quote]

Thanks; just wanted to know if I'd missed something.  gcc (version 4.6) does not warn on a missing default clause with -ansi -pedantic; it might do so with some other combination of flags.

Peter Bigot said:

gcc (version 4.6) does not warn on a missing default clause with -ansi -pedantic;