MicroC can merge sibling Or-States when there is a single transition between them that has no guard on it. Consider the following topology:
...[S11]-t12->[S12]...(states S11, S12 transition t12)
The goal of the optimization is to merge S11 and S12, as well as the static reactions of the two states and the transition action (referred to as “merged actions”). The merge is allowed (considered correct) when the following conditions are met:
●
●
There is no conflict in element assignment and usage between merged actions and actions/ reactions in the other AndState components.
●
There is no conflict in event generation and usage between merged actions and actions/reactions in the other AndState components.
●
When the usage is Out/Inout, the call is regarded as “assignment/events generation” of the actual function parameters.
●
When the usage is In/Inout, the call is regarded as “usage/events test” of the actual function
●
●
● When using GBA, no painting is done for the states that have been merged to another state; only the remaining state is painted.
● A reference to/usage of an element of an array is considered as a reference to/usage of the entire array. For example, if you use MY_ARR[2]=3; there will be a conflict for the whole array or any member of it, such as DI=MY_ARR[4];.
● A reference to/usage of a record field is considered example, if you use MY_REC.F1=3;, there will be a conflict for the whole record or any of its fields, such as DI=MY_REC.F2;.Note: This optimization, when used with the optimizations inline entering/exiting reactions and clutch of state hierarchy might result in an action sequence that is not identical to the action sequence performed without those optimizations. Make sure the difference is acceptable.