$PH/COOL-LCP/How2DefineStateModels.htm [.txt] - RJL051011

-------------------------------------------------------------------

Good examples of textual definition of state models are reviewed below from $CASE/02s522/Team1's Hominid project. First, *setup.c source code files are discussed, followed by a review of their simulation results.

The complete project tree is under $CASE/02f522/Team1;

however, most of its files are included in Appendix B of

$PH/02s522/02s522Team1ProjReptDocs/02s522Team1ProjRepRev1.htm

This well-written and complete final report from Team1's Hominid project includes state diagrams and source code, within which are the textual definitions of state models used in lieu of bde diagrams and bde2SM conversion.

Way down in this file, search for :

"saturn.cs.uml.edu> cat HDsetup.c"

This file contains a section called:

/*

HOMINID DIRECTION SETUP

*/

Function Hdsetup() declares the HD State Model tables,

followed by state action function definitions: HdAction#()

(which I would rename HDaction# and put in HDops.cc instead).

There is a similar organization in the next src file at

"saturn.cs.uml.edu> cat HLsetup.c".

Here is its HLsetup() function definition (edited to save space)

followed by a call to 'HLSMid = StateModelCreateCompletely(.,.)'.

(Note: that the latter calls all XXsetup() functions.)

After each State Model database HD or HL component is created, Active Classes are also created for each subtype HD and HL, along with one or more Active Instances (AI's) (parents of HD or HL objects).

NOTE: The way in which you could create a State Diagram manually, from these 3 arrays HLEventTypes[], HLStates[], and HLTransitions[] should be transparently obvious (at least before Exam2, TBD). SM2bde was intended to automate this conversion from the SM .dat file to a bde .dat file. Note that layout info

must be added or cleaned up by editing the STDiagrams in bde.

-------------------

<pre>

/*

* HOMINID LOCATION SETUP

**/

FUNCTION(

void HLsetup

)

{

hcg_key HLSMid;

hcg_key HLACid;

hcg_key HXAIid;

hcg_key HYAIid;

static EventTypeList HLEventTypes[] = {

{"HL01", "increment"},

{"HL02", "decrement"}

};

static StateList HLStates[] = {

{"0", "HlAction0", HlAction0},

{"1", "HlAction1", HlAction1},

{"2", "HlAction2", HlAction2},

{"3", "HlAction3", HlAction3},

{"4", "HlAction4", HlAction4}

};

static StateTransitionList HLTransitions[] = {

{"0", "1", "HL01"},

{"1", "0", "HL02"},

{"1", "2", "HL01"},

{"2", "1", "HL02"},

{"2", "3", "HL01"},

{"3", "2", "HL02"},

{"3", "4", "HL01"},

{"4", "3", "HL02"}

};

HLSMid = StateModelCreateCompletely("HL State Machine", "HLSM",

ARRAY_SIZE(HLEventTypes),

HLEventTypes,

ARRAY_SIZE(HLStates), HLStates,

ARRAY_SIZE(HLTransitions),

HLTransitions);

HLACid = ActiveClassCreate("HD's advance Active Class", HLSMid);

HYAIid = ActiveInstanceCreate("HYinstance", HLACid, "0");

HXAIid = ActiveInstanceCreate("HXinstance", HLACid, "2");

}

/* end HLsetup() */

--------------

</pre>

=======================

Simulation execution:

(generate log file and replay it using bde):

Appendix B.2 of the Team1 report at

$PH/02s522/02s522Team1ProjReptDocs/02s522Team1ProjRepRev1.htm

contains the Hominid simulation output files:

B.2 Output files : LCPmain.exe

Hominid.dat

hompathlog.txt

hompathlogDB1.dat

logdata.txt

File hompathlogDB1.dat is the database checkpoint file

(database state from which the log begins).

saturn.cs.uml.edu> LCPmain.exe is an execution typescript

which pr_loads this checkpoint (and rejects unknown table rows)

This is followed by an interpreted printout of each replay command action.

File saturn.cs.uml.edu> hompathlog.txt is the log file

from Team1/Hominid simulation test that bde DID replay

thanks to code from projects in $CASE/02f592.

How to read log files:

To comprehend *log.txt file structure I recommend that you inspect

NTansala's structure chart at slide #23 of

$PH/COOL-GEN/gencpp/gensrcStructureCharts_nt.ppt

This shows the switch(token) (an enumerated command name) action calling a corresponding named action routine. For replay implementation details you can inspect the source code at

$PH/COOL-BDE/bdegen13/bde --> $CASE/bdegen13/bde

In particular, inspect functions replay_log() in bde/src/bdeReplay.cc and pr_replay(), encode_token() and doCommand() in bde/pr_util/pr_log.c. Pr_log.c is consistent with and (I hope) upward-compatible from, older and more generic interpreted code in JPsim's OP-class state model.

Bde does not use LCP/JPsim's OP class: bde's code is compiled; it is not an interpreted simulation of state model control flow like LCP.)

In particular, bdeReplay.cc calls

command = encode_token(token);

then, in switch(replayState) case STATE1 it calls

command = do_command(hcg_buffer, token, &idx); command is returned so bde can do application-specific things if desired.

bde/pr_util/pr_log.c contains the encode_token and do_command functions. do_command() case-switches on the token from the first field of the command line. Each case is a different replay command type.

Both Bde and OP have a default command case block, that pr_load's a table row. They rely on pr_load.c's parser to reject erroneous or out-of-view object types and comments.

$PH/COOL-LCP/JPsimIdraw/fig5.idraw is linked to $CASE/95s522/95solc/msrdanov/JPsim/OP/doc/idraw/ and contains the most recent (1995) drawings of JPsim's OP class that I have been able to find. Its slide #9 is a drawing of the piping layout of JPsim. There is also a bde drawing of this layout somewhere, probably in JPsim2bde. Older. simpler versions of the OP-class STD are at slide #7 of $PH/COOL-LCP/ovendocs/OvenController.ppt

and slide 19 of $PH/COOL-LCP/JP2html. Idraw (.ps) files are displayable in linux via ghostview (more elegant than saturn's older version) and in IExplorer via Adobe Reader.

Hominid Project bdeReplay Demo

$PH/02s522/CASE/bdeReplayDemo links to $CASE/02f522/hominidDemo.txt,

a .csh command sequence that sets up and runs the Hominid bde replay demo (on Unix/Linux/X11) at your $CWD (using bde/pr_util from $CASE/02s592/sjaganat's genv12).

Unfortunately the square ring path is not visible as it is in the

Team1 report. However the 's' key steps bde thru the replay and

prints the N/S/E/W direction indicator at the appropriate grid location.