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.