Talk:Virtual finite state machine
From Wikipedia, the free encyclopedia
[edit] Canonical state machine
Am confused here. The canonical hardware models are usually considered the Meely and the Moore models. And folks seem to prefer the Moore as "more canonical" because the state is the only determiner of the output.
The hardware state register is simply either (i) 2 banks of D flip-flops clocked with phases 1 and 2 (or the equivalent) or (ii) a single phase D flip-flop with delay. The output feeds back to the lookup table (made in any of a number of manners -- usually a state decoder followed by encoding logic -- very simple). This is as primitive as it gets -- this is the fully atomized state machine.
So my point is: there doesn't seem to be any thing as an "entry action" and "exit action", rather just a "state action". That is, if we do insist that these two actions are to exist then we can atomize the so-called state further into two successive state actions -- into two (or more) successive states.
I do agree that when designing software a person might create a so-called 'state' -- a sequence of instructions that is entered via a "state table". This pseudostate indeed does have many actions but as an instruction sequence. I've done this myself in my work. In this case, what is an "entry action" versus an "exit action" -- how do you define them? For example, the following table is from Turing (1936) page 120 in the Undecidable. Here we see something more like "pseudostates" with many actions inside each "state" aka m-configuration":
| Config | Config | Behavior | Behavior |
| m-config. | symbol | operations | final m-config |
| b | - | Pe, R, Pe, R, P0, R, R, Po, L, L | o |
| o | 1 | R, Px, L, L, L | o |
| o | 0 | - | q |
| q | Any | R, R | q |
| q | None | P1, L | p |
| p | x | E, R | q |
| p | e | R | f |
| p | None | L, L | p |
| f | Any | R, R | f |
| f | None | P0, L, L | o |
Take any of these rows: what is the "entry action" and what is the "exit action"?wvbaileyWvbailey 17:33, 16 August 2006 (UTC)
= = = = = = = = = = = = = = = = = =
Some comments: In a hardware system the "actions" are called outputs and are produced continuously during a state (Moore model), or in the Mealy model the outputs can be also governed by other input signals. In a software implementation the actions are a sort of event: perhaps a call to trigger a routine or function. In fact these can be generated in four ways: in the StateWORKS terminology there is the "entry" action which occurs when a new state is entered, and this is the most common case. The "exit" action will occur when a state is left. One could imagine a "transition" action but this is not used, for various reasons, in a StateWORKS/VFSM system. Finally we have the Mealy situation, where, without changing state, an input event causes what is termed an "input action" . In some rare cases, one needs to define a condition (inputs) which would cause a transition, and make the same condition generate an input action as well, because the requirement can not just use an entry or exit action. A hardware system's outputs correspond closely to "entry" and to "input" actions. The Turing table shows a hardware system, in any case. It is a Mealy state machine because the inputs cause actions with and without causing transitions. PO,L,L could perhaps be entry actions to State o but in fact the operations are a list of actions to be taken in succession, and sometimes repeated. R, R means take 2 steps right, for example. So I don't think that there is an answer to your question, until the environment is better defined. Although, in StateWORKS, all these successive operations can be itemised in a list of actions (entry, or input, typically) and they will be performed in the sequence in which they have been listed by the editor. There is a need to use a subtle "break" option in such cases. Look at www.stateworks.com for more comments on these topics, and specifically at some of the Technical Notes. PeterWol (talk) 10:21, 1 February 2008 (UTC)
