autogen_back

AutoFSM Usage

Main
AutoGen
Pages

Home
Announce
FAQ
docs
XML Defs
testimonials
downloads

Automated
Options

AutoOpts
Comparison
Man example
Redistribute
Licensing
local use
using getopt

GCC's
Fixincludes

fixincludes

Automated
FSM

description
example
usagefsm

Addons
addon

Project GNU
Home Page

Automated
XDR

xdr project

i This page defines all the valid Automated Finite State Machine attributes. "state", "event" and "transition" definitions are required. The rest ("prefix", "cookie", "<evt-name>", "method" and "type") are optional, as noted.

Please see the example page to see exactly how many of these machine attributes are used.

state
For every valid processing state, you must specify a state name.

event
For every valid event that can cause a state transition, you must specify an event name.

prefix
External value prefix. This will keep the generated external values disambiguated. If you do not specify this, it will default to the base name of the definitions file. Our example FSM specifies ``EX'' for its prefix.

cookie
Each of these must contain C-type plus a name suitable for use in an ANSI procedure definition. It is used to pass whatever arguments you need to the transition handling code. For example, "void* cookie" will pass a void pointer named "cookie".
Note: each name must be preceeded by a space character in order to be correctly separated from its type.

<evt-name>
For any event types that you would like to display in an alternate format, specify the display form with a definition of this type. In the example FSM, the "dash", "bang", "eol", and "comma" events are given special display strings.

transition
Transition entries specify which transitions are valid, based on the original state and the transition event. It may specify an advisory destination state, but if it does not, then the transition defaults to an unchanged result state. Conflicting transition specifications will silently override each other. This makes specifying all state or all event type transitions useful.

Every transition must specify one or more initial state attributes (tst) and one or more transition events (tev). The "next" and "ttype" transition attributes are optional,

tst
Transition initial state. You may specify a list of states, as in `tst = first, second, another;', or you may specify all states with an asterisk, as in: `tst = "*";'

tev
Transition event. You may specify a list of events, as in `tev = evt-1, evt-2, evt-n;', or you may specify all events with an asterisk, as in: `tev = "*";'

next
Next state. You may only specify one. If you do not specify it, the transition will default to not changing state.

ttype
Transition type. Occasionally, it is convenient to handle different transitions with the same code. Often, when you specify multiple states or multiple events in a single transition specification. Specifying this attribute will cause the FSM to invoke the same code. Specifying `invalid' will render the transition invalid, as if it had not been specified before. Specifying `noop' will suppress the emission of code for handling the transition.

method
There are three FSM implementation methods supported, including no implementation. That "method" leaves it to you to supply all the code. You must set the method attribute to one of the following, or omit it entirely:

case
the switch statement in C. A procedure will be emitted that contains a giant switch statement. Each case element will have stylized comments that will enable any code that has been inserted there to be carried forward to new generations of the code. You can see an example of this FSM here.

call
Instead of containing a transition enumeration, the transition table will contain pointers to transition procedures. The main FSM processing routine will indirectly call the proper procedure for handling each transition. The called procedure will be stubbed out and contain the same type of stylized comments that the case version, above, does.

none
No implementation code will be emitted. However, the state, event, transition enumerations and the transition table are all emitted. The emitted header file will contain external declarations for the transition table and transition error procedure, unless you #define the DEFINE_FSM name. That wil cause these to be defined in the compilation unit. See the file agen5/pseudo.def and the output file agen5/pseudo-fsm.h (in the AutoGen-5.18.4 source distribution) for an example of this.

type
If you are generating an FSM implementation, the machine type must be set to "looping", "stepping" or "reentrant". Otherwise, you can omit it or set it to "none".
loop[ping]
A looping finite state machine is the normal implementation. You call it, it initializes itself and runs until a terminal state is reached.
step[ping]
Sometimes, external code must control the loop and it must call a transition `step' when a transition event is detected. For these situations, choose the `step' machine type. The procedure emitted will return the current state at the end of each call.
reent[rant]
This method is much the same as stepping, except that the caller must save the current state and provide it on the next call. In this fashion, an FSM may be used in a multi threaded application.
none
If you do not specify an implementation method, you may omit the ``type'' attribute.



top  Viewable With Any Browser  Valid XHTML 1.0!


AutoGen, AutoOpts, columns, getdefs, AutoFSM, AutoXDR and these web pages copyright (c) 1999-2012 Bruce Korb, all rights reserved.

Return to GNU's home page.

Please send FSF & GNU inquiries & questions to gnu@gnu.org. There are also other ways to contact the FSF.

Please send comments on these web pages to webmasters@www.gnu.org, send other questions to gnu@gnu.org.

This article, Copyright © 2000-2002 by Bruce Korb

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. Last modified: Sat Aug 30 11:01:51 PDT 2014