state machine implementation

M

Mark

Hello,

I was reading
http://www.netrino.com/Embedded-Systems/How-To/State-Machines-Event-Driven-Systems
and later on in the article the author provides simple implementation of
finite state machine; the implementation is indeed very simple and clever,
yet I can't precisely understand some parts. Here is the implementation:

typedef short Signal;
typedef struct Event Event;
typedef struct Fsm Fsm;
typedef void (*State)(Fsm *, Event const *);

struct Event
{
Signal sig;
};

struct Fsm
{
State state__;
};

#define FsmCtor_(me_, init_) ((me_)->state__ = (State)(init_))
#define FsmInit(me_, e_) (*(me_)->state__)((me_), (e_))
#define FsmDispatch(me_, e_) (*(me_)->state__)((me_), (e_))
#define FsmTran_(me_, targ_) ((me_)->state__ = (State)(targ_))

My questions will be:
1. Not quite obvious the reason to define 'Signal' as an alias to short.
What's the profit ?
2. Is it necessary to define Event as a structure?
3. IMO would be better for readibility to have inline functions instead of
macros?
4. To me the more obvious solution would be something like:

struct fsm {
int event;
int state;
int (* fsm_callback)(int eve, int st);
};

/* state table */
struct fsm fsm_table[] = {
{ STATE_INIT, EV_1, &f1 },
{ STATE_UP, EV_2, &f2 },
{ 0, 0, NULL }
};

PS. Read the article again, but failed to grasp the benefits, perhaps
someone may point out. Thanks.
 
P

Pascal J. Bourguignon

Mark said:
1. Not quite obvious the reason to define 'Signal' as an alias to
short. What's the profit ?

So that you can change the definition later, in case you have more than
65536 different signals.

2. Is it necessary to define Event as a structure?

Nothing is necessary.

3. IMO would be better for readibility to have inline functions
instead of macros?

What difference would that make?


4. To me the more obvious solution would be something like:

So what?

PS. Read the article again, but failed to grasp the benefits, perhaps
someone may point out. Thanks.

The benefit of what? Of FSM or of that particular implementation?
 
K

kym

In comp.programming Mark said:
Hello,

I was reading
http://www.netrino.com/Embedded-Systems/How-To/State-Machines-Event-Driven-Systems
and later on in the article the author provides simple implementation of
finite state machine; the implementation is indeed very simple and clever,
yet I can't precisely understand some parts. Here is the implementation:

typedef short Signal;
typedef struct Event Event;
typedef struct Fsm Fsm;
typedef void (*State)(Fsm *, Event const *);

struct Event
{
Signal sig;
};

struct Fsm
{
State state__;
};

#define FsmCtor_(me_, init_) ((me_)->state__ = (State)(init_))
#define FsmInit(me_, e_) (*(me_)->state__)((me_), (e_))
#define FsmDispatch(me_, e_) (*(me_)->state__)((me_), (e_))
#define FsmTran_(me_, targ_) ((me_)->state__ = (State)(targ_))

My questions will be:
1. Not quite obvious the reason to define 'Signal' as an alias to short.
What's the profit ?

Normally 16 bits. Please remit via paypal by end of month.
2. Is it necessary to define Event as a structure?

No. But it's a standard way to describe ADT in C.
Perhaps also Signal should be defined that way, too.
3. IMO would be better for readibility to have inline functions instead of
macros?

A macro looks like a procedure/function call. So there is no "readability"
issue apart from defining the macro. The optimizer will handle them much
better then function calls, although gcc's "inline" these days does an
almost identical job anyway.
4. To me the more obvious solution would be something like:

struct fsm {
int event;
int state;
int (* fsm_callback)(int eve, int st);
};

/* state table */
struct fsm fsm_table[] = {
{ STATE_INIT, EV_1, &f1 },
{ STATE_UP, EV_2, &f2 },
{ 0, 0, NULL }
};

PS. Read the article again, but failed to grasp the benefits, perhaps
someone may point out. Thanks.
 
R

Rui Maciel

4. To me the more obvious solution would be something like:

As I see it, you expected that the example demonstrated the way of
implementing this while it actually is a way of implementing this. The
difference is subtle but considerable.


Rui Maciel
 
J

Jorgen Grahn

["Followup-To:" header set to comp.lang.c.]
What difference would that make?

Readability, just like Mark wrote. The macros looked like:

#define FsmDispatch(me_, e_) (*(me_)->state__)((me_), (e_))

The type information is missing, so I have a hard time seeing what
goes on. Also, me_ is evaluated twice, which may come as a nasty
surprise to the user if the expression has side effects.

/Jorgen
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top