In GCC, it's legal to have an array of gotos, so this should work... and save a lot of space (and execution too, I would think)
void *jumptable[]={ &&label0, &&label1, &&label31}; goto *jumptable[TWSR>>3]; label0: //code for state 0 return; label1: //code for state 1 return; label31: //code for state31 return; On Fri, 23 Dec 2005 17:49:35 +0100 Vincent Trouilliez <[EMAIL PROTECTED]> wrote: > On Fri, 2005-12-23 at 17:17 +0100, David Bourgeois wrote: > > I have a TWI interrupt routine inspired from the proycon avrlib and which > > handles multi-master transmissions in an atmega48. > > It's basically a sequence of cases for every value of the twi status. > > > > Right now, my twi code is 780 bytes long but 292 are for the SWITCH alone, > > while only 266 are for what I'm actually doing in the cases. > > > > Is there a better way to write this? I've been told that a if/else if > > sequence could be more efficient but can't really understand why. I guess > > this also depends on the compiler. What about AVR-GCC in such a case? > > And even if I have to write all this ISR in assembler, could I be able to > > reduce this code significantly? > > > If you are willing to write assembly, then there is room for significant > improvement I think: > > > PUSH TWI_STATUS_REG > RETURN > > Two instructions, hard to beat ;-) > That was for an Intel 8051 but surely it can be adapted for an AVR ??? > > In the 8051 the I2C status register's lower 3 bits are unused, if in the > above code, so you have 8 bytes to deal with each status case. > > Basically it's a look-up table with the status byte as the index. Stated > like this, you can now translate it into C statements: write separate > functions for all the various cases, put there address in a table of > pointers, and use the TWI status byte as the table index to retrieve the > matching function pointer, then jump to the required function. Done. > Obviously, the more cases you have to process, the more > efficient/interesting the look-up table becomes. Doing it for only two > cases would be a tad overkill ;-P > > Sounds complex but it should still occupy much less than 292 I would > think !! > > > HTH, > > > -- > Vince > > > > _______________________________________________ > AVR-GCC-list mailing list > AVR-GCC-list@nongnu.org > http://lists.nongnu.org/mailman/listinfo/avr-gcc-list > _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list