Re: [boost] Meta State Machine library review starts Monday

Subject: Re: [boost] Meta State Machine library review starts Monday
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2009-11-28 17:49:29

Hi Darryl,

> I found code size of stripped executables compiled with gcc 4.3 to be
> quite reasonable - especially at high optimisation levels, although
> still about twice the size (the docs state) VC9 achieves. I'm assuming
> that the large sizes mentioned are simply due to the generated files not
> being stripped.

Correct. Stripping will greatly improve the executable size,
eventhough it'll still be more than what VC produces.

> I was unable to compile the euml example - I haven't investigated the
> errors yet.

g++4.3 should manage this. Please contact me if you need any assistance.

> I had hoped to pick what I'd consider a realistic use for a high
> performance FSM tool (a low level comms protocol) and do a basic mock-up
> implementation using MSM. However a reasonably typical layer 2 protocol
> (LAPD) has 8 states and a transition table that in a condensed form (row
> for each event, column for each state with the column describing the
> actions and transition) is 10 pages long, so it is pretty obvious I
> can't do that... Its likely that a bit of refactoring could bring the
> total number of transitions down somewhat using composite states, but
> the number of events to be handled exceeds the typical limits for number
> of transitions so this still seems hopeless.

8 states doesn't seem like a huge number to me. How many transitions
are we talking about?
I'm not so sure that it can't be done, especially as you're using g++
4.3 which is the best compiler with Msm. I managed to compile 100
transitions in about 40s (while running in a VM). I'm pretty sure the
compiler can manage more.
Supposing that every of your 8 states has a distinct transition to
every other state including itself it'd be 64 transitions, which your
g++4.3 will easily manage. You can even allow yourself to have more
than one to every state.
In the very worst case, if you had so many events (say more than 100)
that g++4.3 itself would crash we could easily group events with the
same source and same transition inside the same event and reduce the
number of transitions to what g++ would manage.

> At this point, I really like what msm is trying to do - it just doesn't
> quite do it for me in a practical application. Maybe that just means
> waiting for Moore's law and compiler technology to catch up?

Well, it'd be a solution but hopefully we won't have to wait yet ;-)
Seriously, I'd be happy to work with you on this one. It'd be quite
fun and I'm pretty confident it can be done if I'm right about my
assumption on the number of transitions.

Regards,
Christophe