RE: [avr-gcc-list] Re: C vs. assembly performance

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Vincent Trouilliez
> Sent: Saturday, February 28, 2009 7:41 PM
> To: address@hidden
> 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.