RJLRef: LCPupdateProject.txt - RJL 040401,041024,050926 (in $PH/04s522/04s522Projects/04s522LCPupdateProject) Part I: History of the LCP Action Routine dispatch problem: -------- [This reviews old history of LCP State-to-Function mapping project prior to the latest 04s522 project by ajlopez.] RJLRef: $CASE/02f522/LCPphase2andBdeReplay.hlp was RJL's revision for 02f522 of LCPphases2and3.hlp in 02s522. That is also in ~/public_html $PH/02f522/LCPphase2andBdeReplay.hlp, There, I included final results of the progress made during the 02f522 Hominid project and 02f592 Inspection project.] The 02f522 LCPproject (John Sharko and Tom Kneeland) attempted to upgrade LCP to alpha 64-bit platforms in the same way that BDE had been upgraded. It is in $PH/02f522/jpsimreportRev03f.txt They were able to rebuild jptest.exe with genv12 on saturn but the run command jptest.exe JuicePlantTransfer jpbatch.vdf jttest aborted because of improper log/replay interaction. Logging and replay are optional and more stable now. (In 05s523, genv12 was upgraded to chgenv13, for better compatibility with bde log and replay.) 02f522 modified the repository version in 95s522/95solc: This file shows that diff produced 416 lines, including 245 from lcp_main.c and 65 from processevent.c. These two .c files are each about 350 lines. $CASE/02f522/JPsimProj_js_tk/tkneelan/JPsim/olc/src/lcpdiff_2kf.vs.95s [Part II: [The LCP Update project actually done in 04f522:] This new method for ActFunc pointer access in LCP is recommended as a project for one person in 04f522: Its goal is to replace temporary work-arounds of chgen's missing unsigned long schema field type which could hold pointers, and the incompatibility of persistent pointers in .dat files with relinking or non-shared-memory distributed applications. One such work-around uses strcmp to search an FT table for STcurr->ACtname. This approach was used in $PH/02s522/02s522Team1ProjReptDocs/02s522Team1ProjRepRev1.htm The 04f522 project is adapted from alternative (3) of Section II.8 of $PH/02f522/LCPphase2andBdeReplay.txt which describes 3 work-arounds for runtime access to a function address from a STate table row: (1) Store the address into two 32-bit parts; (2) Store the address as a c16 field of 16 hex digits; (3) Store an index into a pre-linked function pointer array. Only (3) entirely avoids saving a pointer in persisent storage. But it requires a 2-phase LCP simulation process: (a) a setup phase performed infrequently, when state model data or LCP code is changed; (b) a run phase, repeatable many times to execute actual simulations. This is similar to my 02s522 proposal, except the LCP setup phase generates LCPFuncTbl.h (along with SM,ST,TR and EN data); the LCP setup phase MUST be executed to get this .h file, that now must be compiled into the run phase which #includes LCPFuncTbl.h. Part III: (revised - RJL050926) {Results from the 04s522 LCPupdate project by ajlopez.] This project was finished concurrently with the 02f522 Hominid project and 02f592 Inspection project.] These were simulations that attempted to couple an application which logged changes to a file or channel, that was replayed by BDE used as a display device. The 04s522LCPupdate project refactored lcp_main into two separate programs (each containing a main): lcp_setup.c and lcp_main.c. These two parts must be executed separately, because run phase compilation depends on .h file output from setup phase. [The previous LCP simulation program also had 2 parts but its command line options were confusing to the user.] 04s522LCPupdate project requirements: ----------------------------------- Revise the current STate table below. Redefine ST's action pointer field as an I4 index into FuncTbl[].) Initialize this index in an enhanced version of the OLC/LCP setup method StateModelCreateCompletely(). For this project, change only the comment for field ActFunc and its Altname (not used) in table ST. My original intent was to modify StateModelCreateCompletely() to associate the MSHexDigit of FuncTbl index with a State Model and the LSHexDigit with its STate table row number. This creates a composite 8-bit index into a pre-allocated FUncTbl[256] array, and a unique index into that table for each ST child of that SM. However this turned out to be unnecessary, at least until namespaces are introduced: [Update 040913: One sequential array holds all ST ActRtn index entries for each State Model in the application (all of which are now created sequentially by one process).] The current ST table for Team4's Hominid project is in $PH/02s522/02s522Team1ProjReptDocs/02s522Team1ProjRepRev1.htm The Team1 (not Team4) ST table was declared thus: --------------------------------------- State ST /* states */ { STid StateId c8 1 /* the primary key */ SMid StateAStateOfThisStateMachine c8 1 /* The state machine */ /* containing the state */ ActName StatesActionRoutineName t32 0 /* Action Routine Name (c32)*/ ActFunc StatesActionRoutinePointer i4 0 /* C pointer to function */ Name StatesName t80 0 /* The name of the state */ } ------------------------------------------- Table ST declares ActName (c32) and ActFunc (i4) as persistent fields. ActFunc now contains the index ActFunc into array FuncTbl[]. This index is a new intepretation of the current I4 'address' field. It avoids a search loop for an FT.Actname that matches ST.Actname. The FuncTbl[] array is NOT in the .sch file: it cannot be declared in schema.h, because the EERD knows nothing about state models or their actions. The pr_*.c routines contain no references to FuncTbl[]. AJLopez' enhanced the LCP setup phase 1 to declare FUncTbl[] as a .h file so the LCP run phase 2 (main loop) can #include it, after its address field is initialized by the linker. The LCP dispatcher's main loop calls the doTransition routine for eacn dispatched event. doTransition calls the ActName function i directly via the indexed array: (**FuncTbl[(ActFuncIndex=(STcurr->ActFunc))]). The Team1 Hominid project was the test case for LCPupdate project. Here is its function pointer array declaration (initialized at link time): ----------------------------- saturn.cs.uml.edu(347)> m $CASE/04s522/lcp04s/lechner/lcp/include/HMfuncptr.h void (*FunctTbl[])= { HdAction0 ,HdAction1 ,HdAction2 ,HdAction3 ,HlAction0 ,HlAction1 ,HlAction2 ,HlAction3 ,HlAction4 }; ------------------------ Current use of ActFunc index in the STate table; Here is the actual DoTranstion routine in $PH/COOL-LCP/lcp04s/ajlopez/lcp/olc/processevent.c (to be used in future projects incorporating lcp/olc) DoTransition runs during LCPmain (runphase 2) and calls ActiveInstanceSetState(AIid, StateGetName(STid)) whenever the currently dispatched event enables a state transtion. The state change involves updating AIcurr->State (and STcurr), after which DoTransition uses STcurr->ActFunc to index into FuncTbl and execute the action routine names STcurr->ActRtnName: void DoTransition(hcg_key STid, hcg_key AIid, hcg_key EIid) { void (*p)(hcg_key); // declare p as ptr to funcion with key as argument. /* First, put the active instance into the correct state*/ ActiveInstanceSetState(AIid, StateGetName(STid)); /* And call the action routine (Alfredo Lopez in 04f522 */ p = FunctTbl[STcurr->ActFunc]; i /* get address */ (*p)(EIid); /* jump there */ } ---------------- ========================================================= Future LCP refactoring projects: [rev. 041024, 050926 - RJL] --------------------------------- Prior design choices were not optimal, but they reduced the scope of ajlopez' 04s522 project. They allowed pointer-based function tables to be declared for LCP, generated automatically and invoked efficiently from the LCP iphase 2 runtime interpreter for any set of state models. Future Generalizaion of ActFunc indexed array (FuncTbl) access: ------------------------------------------------------ [A later refactoring can redeclare FuncTbl[ActFunc] as FuncTbl[SM#, ST#] with SM# and ST# as separate indices. (analogous to the state code in the bdeState project). This is deferred so as not to break existing code with a single I4 ActRtn index field in table ST. [When gencpp redeclares AC and SM struct declarations from chgen as class objects for gencpp, FuncTbl may need further refactoring to declare a separate SMFuncTbl[] array for each State Model of an Active Class. This can be done in the LCP phase 1 (Initialization) and in bde2SM which converts bde diagrams into state models.] [A future schema will include table FT and add an ST.FTid fkey. Another alternate is to add table FT and a mapping entity SF which associates tables ST and FT. ST.ActFunc can be replaced by SF.FTid and SF.STid. Both alternatives move the ActFunc index to table FT. This second altenative permits a sequence of ActName functions to be called from one ST action. It also requires omitting ST.ActName because it uses child_loop(ST, SF,..) to execute a sequence of ActNames. BY interpreting the ST to AF child-set as a FORK rather than sequential operator, LCP could activate multiple concurrent ActFuncs at a lower level. This has lowwer priority, because concurrent peers can already be invoked by generating multiple event messages to Active Instances. These can simulate concurrent services by interleaved execution in response to their incoming events. Future Guard Condition code generation for LCP: ---------------------------------------- It would be handy to model guard conditions like action routines: For example, as #defined abbreviations as in the 04f522/asgnt3 notation for reverse engineering to a precise STD of the resize_node function in bde/src/nodeops.cc. This notation used for reverse engineering of the Node Resize method in 04f522/asgnt3 might also be useful in forward engineering (code generation from an STD). A 2kf522 project began this work using schema tables FT and SF: $CASE/2kf522/LCPGuardConditions Their goal was to parse guard expressions that augment event labels on state transitions. Unfortunately that was before lcp_main.c with tables AC and AI. So it would have to be updated to the current olc source code. Future TimedEventrQueManager Project: -------------------------------- Another recommended project is to complete the Timed-Event que and TimedEventrQueManager projects of J McCarthy in $CASE/2kf522/jdmccart/tqsrc and Xin Sun/Guangyi Li in $CASE/2kf522/ These were parallel projects. Neither was completed. Both teams started from OMcGonagle's Toggle FlipFlop simulation http://www.cs.uml.edu/~lechner/96f522/omcgonag/doc/OMcGFFwd97.doc It is not clear whether either used lcp_main, AC and AI. They may have implemented only simple test drivers, not all of logsim.]