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.8.6 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.