| View previous topic :: View next topic |
| Author |
Message |
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
| Switch Fall Through |
 Posted: Tue Aug 04, 2020 10:48 am |
 |
|
Hi all,
I'm building a sort of cooperative scheduler RTOS_ish frankenstein
(yes i know that's the doctor not the monster)...
My time requirements are soft, having only 1 single hard time requirement which is interrupt driven.
I'm building it based on switch statements - Might not be the best method but at least i know what to expect.
Everything is working properly so far, despite the Q43, however Thinking about optimizations, i came up with the following:
pseudo:
Code:
| Code: | Switch (case_var)
case a:
{
if(condition is met)
{
do this;
break;
}
else
{
case_var=b; //to maintain case order
//no break, so it falls through, avoiding go around
}
}
case b:
{
Do that;
}
|
I'd appreciate your comments on the idea.
G.
_________________
CCS PCM 5.078 & CCS PCH 5.093 |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19219
|
|
| Posted: Tue Aug 04, 2020 12:28 pm |
|
|
Not really wrong with that.
What chip?.
On the PIC16/18, if you have a switch statement, with more than about
five states, and no 'default' state, the compiler will build a jump table
instead of coding every test individually. Makes the code very much more
efficient in operation. |
|
|
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
|
| Posted: Tue Aug 04, 2020 2:28 pm |
|
|
I'm using the PIC18F47Q43 as discussed in another prior thread here... i have not encountered the Ram issue yet...anyways.
To make sure i get it straight:
Larger switches without default, get turned into a jump table, right.
Most of mine (6 switches so far) have about 10 to 20 cases, however i did implement defaults for... safety?... I'm sure i can get rid of them to get into that jump table goodness.
I tried, the "idea" discussed here, and i got considerable gains in execution time so I'm pretty happy about that!
It allowed me to "schedule" certain cases using the "Seconds" of the RTC or yield to the next task without having to go around the loop to the next case.
(a "frequent" task in my system is every 2 seconds for example).
_________________
CCS PCM 5.078 & CCS PCH 5.093 |
|
|
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
|
| Posted: Tue Aug 04, 2020 3:16 pm |
|
|
holy crap! i removed the defaults and just by looking at the debug printfs i can already see its faster!
I have the LCD updating every 5 seconds. Before removing the defaults, i sometimes got time showing 01 or 06 seconds for example instead of straight 00 or 05 seconds for example as it should because its a every 5 second task...
I was not really bothered by this as my time requirements are SUPER Soft.
I'm no longer off by that random second!
Thank you!
_________________
CCS PCM 5.078 & CCS PCH 5.093 |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19219
|
|
| Posted: Tue Aug 04, 2020 11:34 pm |
|
|
The 'silly' thing is that if you have a simple range of switch values, there
is nothing to stop you just coding the equivalent to a 'default' yourself. So
(for example), if you have switch values from 1 to 10 (say):
| Code: |
if (val<1 || val>10)
{
//this becomes the 'default' code
}
else
{
switch (val) {
case 1:
case 2:
///etc...
case 10:
}
}
|
The result still gives you the much faster behaviour of the jump table.
But anything outside the tested values is handled by the 'if'.
At low numbers of tests, the extra 'setup' needed for the jump table
makes it not worthwhile. So the compiler on just a couple of tests
instead does individual tests, but for a switch with a lot of cases, it
is very much more efficient using the table.
Glad the table approach proved worthwhile for you.  |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
