The pointers would be even slower than the switch statement For realtime stuff like clock ticks, I suggest taking a leaf out of TK’s book… You have a counter which is incremented when the clock ticks, and then in the user_tick, you test that counter, and if it is not zero, you call your function. Your switch statement is bang-on though.
I’ll leave the double-switch thingy to one of the C gurus
I’m ~99% sure that the dual switch stuff is not allowed.
You could for example put a switch block or “if/else if/…/else” into a case of a switch.
Another way is for example to create a 16-bits value “tmp” out of the two 8-bits values “i” and “j” and then to the case stuff on tmp:
uint16 tmp;
uint8 i, j;
tmp = (((uint16)i) << 8) + j;
case 0x0100: //-> corresponding to i = 1, j = 0
...
case 0x0201: //-> corresponding to i = 2, j = 1
On an 8-bit processor, it will certainly be cycle and memory consuming so if i and j are in the range of [0 … 15] then you could even code the combination on one byte by doing only a shift of 4 on i. This would be much better. Actually any combination which would lead to a tmp coded on 8 bits would be better.
In old C compilers (I can’t talk much for SDDC), switch statements are converted to jump tables, which run much faster then if/else statements or function invocations. I’m not great at explaining things, but wikipedia should help.
So to answer your question, use a switch statement. Calling a function is “better” style, but if you want efficiency, you’ll need to “inline” the function body in the switch statement.
About four months late… and I think that was all said in the previous posts ;D But you’re correct!
So to answer your question, use a switch statement. Calling a function is “better” style, but if you want efficiency, you’ll need to “inline” the function body in the switch statement.
Maybe sometimes true but not in the case of SDCC. When you inline the function, the switch statement compiles entirely differently, and it kills the efficiency. It’s better to call the function from the switch statement - and I mean call a function, not using a function pointer.
Just to add something interesting to my post… The jumptable generated by a simplified switch/case statement is generally faster than a series of 'if’s , but there is some code that is always present for the jumptable, so if you only have a few options, or if you won’t be using ‘break’ at the end of each case, sometimes the ‘if’ is actually faster. Sometimes…
Hi, I hope you all read the article at “How to Implement Branch Tables in C” at the end of the wikipedia page. It is very interesting. He advocates the use of function pointers, without switch at all but a real function table. It has pros and cons he well analyzes, and in the embedded world BTW.
Nah I just tried it and analysed the output I’ve read about 1/4 of that document so far and he has already mentioned some of the things I’ve posted about above, for EG:
Maybe sometimes true but not in the case of SDCC. When you inline the function, the switch statement compiles entirely differently, and it kills the efficiency.
A quick survey of the documentation for a number of compilers revealed some interesting variations. They all claimed to potentially perform conversion of a switch statement into a jump table. However, the criteria for doing so varied considerably.
In the case where one has, say, 26 contiguous indices, each associated with a single function call (such as the example above), the compiler will almost certainly generate a jump table. However, what about the case where you have 26 non-contiguous indices, that vary in value from 0 to 1000?
What I’ve found so far was that SDCC would compile very heavy ASM if the code was not just-so. The only solid recommendation that can really be made here, is to try stuff out and see how you go… What I tried, and what was mentioned in that article (pointers to ram not rom), differ somewhat… But I can tell you that when I started to head in the direction suggested there, the code size exploded.