Of course you're right, if you only have one case, even a normal switch
statement makes no sense at all. A simple IF does it as well.
Anyway, this intrinsic has its advantages. For all these ISRs with a vector
register (and on the 54xx, almost ALL ISRs have one, including the reset), I
use an ISR of the following form:
interrupt(TIMER1_A1_VECTOR) timera1x_handler(void){
__asm__ __volatile__("add %[src] ,r0 ":: [src] "m" (TA1IV));
__asm__ __volatile__("reti "::); // NO INT
__asm__ __volatile__("jmp timera1_cc1_handler "::); // CC1
__asm__ __volatile__("jmp timera1_cc2_handler "::); // CC2
__asm__ __volatile__("reti "::); // RESERVED
__asm__ __volatile__("reti "::); // RESERVED
__asm__ __volatile__("reti "::); // RESERVED
__asm__ __volatile__("reti "::); // RESERVED
__asm__ __volatile__("jmp timera1_ifg_handler "::); // IFG
}
interrupt(NOVECTOR) timera1_cc1_handler(void){}
interrupt(NOVECTOR) timera1_cc2_handler(void){}
interrupt(NOVECTOR) timera1_ifg_handler(void){}
Doing so with a case statement that results in the same efficience would be
great, but this can only be done with direct compiler support.
Just a function that checks (at runtime) whether the result is even and in a
given range is useless if no code is generated to take advantage from this
information.
I don't think the original intrinsic will do any runtime checking. (I've never
seen an IAR or CCE assembly output) But I guess It just generates a jumptable
like above, filling the 'gaps' where no case exists with a dummy
jump behind the case statement. Any function call would be counterproductive.
It is, however, not advised to use an IV register as parameter to a normal
switch statement. It's possible that you'll read the register once for every
case statement, which of course won't work since the register is
cleared with the first read.
JMGross
----- Ursprüngliche Nachricht -----
Von: Paul F. Sehorne
An: GCC for MSP430 - http://mspgcc.sf.net
Gesendet am: 14 Jun 2010 17:31:55
Betreff: Re: [Mspgcc-users] intrinsic function __even_in_range
I understand the goal of __even_in_range. I saw in the IAR disassembled
code what it accomplishes. And I understand the need if the switch
statement actually had 34 case statements, but in this code there is
only one case statement. So, other than for educational reasons, I
don't see the value of spending my time trying to figure out how to
write the equivalent routine.
I did write a routine that confirms (at runtime) that the passed in
value is in range and is even (lsb is 0); in which case the value is
just passed back to the program, and if it does not meet these criterion
zero is passed back (again, at runtime). I could further improve this
routine by moving the code in the one lone case statement into the
assembler routine. And I would like to revisit this function at a later
date, for educational reasons and to eventually have an __even_in_range
function when needed for multiple case statements. But for the time
being I am content to move on to other more pressing issues that are
holding up the completion of my port of the eZChronos firmware to mspgcc4.
If I am making a mistake by passing on this for the moment, please point
it out to me.
Paul
