> -----Original Message----- > From: > avr-gcc-list-bounces+eweddington=cso.atmel....@nongnu.org > [mailto:avr-gcc-list-bounces+eweddington=cso.atmel....@nongnu. > org] On Behalf Of Vincent Trouilliez > Sent: Saturday, February 28, 2009 7:41 PM > To: avr-gcc-list@nongnu.org > Subject: Re: [avr-gcc-list] Re: C vs. assembly performance > > > I switch on an unsigned byte, with contiguous values (0-24). > A Function table sounds elegant to my ear, but it would mean 25 > functions ! In my case the work is done in-situ, within the switch > statement, as it's takes only 2 or 3 statements to process a givne > "case". Using functions would be both overkill and overwhelming to > manage I think !! ;-) >
It is no more overkill and overwhelming than dealing with a single contiguous switch statement with 25 cases. I think it's just a matter of perspective. The one good thing is that each function really encapsulates a single idea and has nothing else, which *may* make maintenance easier. Implementing it this way really separates the ideas of 'making some choice' from the 'implementation of a single choice', rather than conflating the two together in a single massive switch statement. Yes, your switch sounds like a candidate for a function table. However, like everything in engineering, there are trade-offs. The trade off here is the overhead for each function, plus the slight overhead for checking the range of the value used to index into the table. To be fair, you would have to write it both ways and see which produces the smaller code. However, the other advantage for the function table is that you can guarantee that it will take the same amount of time, for each value, to start executing its associated function. With an if-else-if structure, the longer down the if-else-if chain you go then the longer it takes to execute the associated code. For a switch statement, it all depends on how the compiler generates code for it, which can change as you add more cases or remove cases from the switch. This leaves you out of control with regards to timing. _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
