Topic
  • No replies
SystemAdmin
SystemAdmin
15 Posts

Pinned topic MircoC 3.0 optimzation option

‏2009-02-04T17:53:49Z |
Question:

Hello,

I have concerns about the code efficiency of MicroC, so I am interested in MicroC optimization option.
But, some optimization affect sequence of generated C statements, which results that C is different from what user expects from model.

If optimaization makes generated C statement sequence different from the sequence without optimization, let's call it "not safe."

Otherwise, let's call it "safe."

I believe, "Not safe" optimization is:
"Clutch Entrance To State Hierarchy"
and other optimizations are "Safe."

Old RiMC 2.0 training presentaion mentioned about
"Clutch.." option that:
Without optimization, the following sequence would have been
performed:

Consider action Ai on transition Ti, entering reaction E1 for state Si
Then:
A0, E1, A1, E11, A2, E111

After $B!H(Jclutching$B!I(J the sequence will be:
A0, A1, A2, E1, E11, E111
And as far as I tried with RiMC 3.0, it still holds with 3.0. This is
the reason I think "Clutch..." is "Not safe."

But "RiMC Programming Style Guide" mentions about "Merge State
Sequences With No Guard on Transitions"
option that:

Note:
This optimization, when used with the optimizations inline
entering/exiting reactions (see page 72) and clutch of state hierarchy
(see page 78) might result in an action sequence that is not identical
to the action sequence performed without those optimizations. Make
sure the difference is acceptable.

It means combination of "Merge..." + "Inline entering.."
or "Merge..." + "Clutch..." can be "Not safe."
But, I could not find : for what kind of model structure this happens.

Would you please let me know ?

I would like to know:
1. What are "Safe" optimizations and what are "Not Safe"

2. With what kind of model structure "Not Safe"
optimization generate different sequence than original.
Answer:
This is very much a non-trivial subject.

Always "Safe":
(1) Reuse Timout Variable
(2) Inline Default Test
(3) Inline "Need Another Step"
(5) Merge State Sequences with no Gurad on Transition
This optimization (5) is always safe, sometime
it is not possible to do, so the optimizer will ignore the
request.
Sometimes "Not Safe":
(4) Clutch Entrance to State Hierarchy
(6) Inline Entering/Exiting Reaction

Regarding those "Not Safe":
The difference might raise when having entering and/or exiting reactions

When the states involved (include up to the transition LCA) does not have entering nor exiting reactions, there will be no difference in the behaviour.

The description in "RiMC Programming Style Guide" about "Merge State Sequences With No Guard on Transitions" is wrong - it should regard ONLY clutch and entering/exiting reactions, not at all merge states. So the title is wrong.

I have attached here example. Please look at it, and show it to those interested in the differences, as the benefits from using the optimizations are significant, could be more than 35% of the compiled code size!! so they worth the time to study the meaning of them.

In the "m1_all_opt.c" all optimizations are allowed, where in "m1.c" (4), (5), (6) are dissabled.