Add generating "switch case" as "if else"

[daminoss]

Update code generation to change "switch else" within component and state machine generated code by "if else" and thus by enabling an option in build configuration.

[eugenschindler]

Just interested: what is the use case of having if instead of switch?

[mohamedaminebennasr]

In general, in embedded system "if else" is better than "swith case", because in most cases "switch case" generate a jump table and in some chip jump table is in RAM when running (esp8266 as example). Given that in ESP8266 we do not have much RAM memory, we need to save RAM by changing "switch case" by "if else" ("if else" statement is stored and runned from ROM)

[abstraktor]

So a Switch Statement will be the one to use starting from a particular number of branches? What are use cases for using a switch? I’m asking primarily for curiosity.

Von meinem iPhone gesendet

Am 26.01.2019 um 12:18 schrieb mohamedaminebennasr [email protected]:

in embedded system if else is better than swith case, because switch case generate a jump table that increase firmware size.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[kbirken]

Performance-wise, execution of a switch-statement based on a jump table will be O(1). Chained if-else-statements will be O(N), although performance can be optimized if the relative frequency of the cases are known. But memory-wise, a switch statement might waste memory, esp. if the case-values are not consecutive. So yes, it's a trade-off. And as it seems on small embedded systems memory is so tight that one would accept long if-chains to avoid using memory at all...

[slisson]

Isn't it the job of the compiler to do this optimisation?

[bkolb]

The compiler does not necessarily know what you want to optimize for.

Sascha Lißon [email protected] schrieb am Sa. 26. Jan. 2019 um 19:57:

Isn't it the job of the compiler to do this optimisation?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mbeddr/mbeddr.core/issues/2037#issuecomment-457856093, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVsBcqlWI5vFNNJHfqDOGXsNQUbIvxxks5vHKUtgaJpZM4aTdoB .

[slisson]

That's why there are compiler options, to tell him. A switch is the higher level construct. Avoiding it just reduces the possible optimisations. Sounds like a workaround for a misconfigured compiler.

[bkolb]

Not all compilers allow all kinds of optimizations. I was recently working with xc8/pic16. In its free version it does not allow any optimization. Even in some commercial versions there is not much you can influence

Sascha Lißon [email protected] schrieb am Sa. 26. Jan. 2019 um 20:28:

That's why there are compiler options, to tell him. A switch is the higher level construct. Avoiding it just reduces the possible optimisations. Sounds like a workaround for a misconfigured compiler.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/mbeddr/mbeddr.core/issues/2037#issuecomment-457858306, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVsBei16eQwJYH78RyAfr_IjI_ZTfAHks5vHKxUgaJpZM4aTdoB .

[stephaneberle9]

A detailed study of what kind of optimizations are available for the switch statement can be found here: https://pdfs.semanticscholar.org/c385/0cfb3dceab66aac52bce50d9e4c0a2bec19c.pdf

At our end, we have analyzed the impact of using or not switch/case in a bigger state machine that we have implemented for customer project. By manually replacing all switch/cases by if/else statements we were able to drill down the initial RAM usage of approx. 2KB by 1.6KB to as less as 400 bytes. In a system where the total amount of RAM being available for the application is as little as 15 KB, this makes quite some difference.

And also generally, in embedded software coding it is not true that you can write your code "just anyhow" and will be able to get good results by only relying on the optimizations that a compiler might do. In many situations the only choice is to write "strange looking" C code to make sure that memory footprint, performance and other limitations are met.

With mbeddr, we are in the lucky situation that we can let look the mbeddr level source code "as we like", and let the "strange looking" C code become subject to the generated code where it "disturbs" much less. Obviously, we're not going to enforce any such choices like switch/case or if/else in a hard-coded way. Instead a new build config item will give users the possibility to make the trade-off that Klaus has mentioned a earlier comment of this thread.