RJLRef: ~/public_html/04f522/04f522LCPupdateProjects.txt - RJL 040401, rev. 041024

Future LCP update projects: [rev. 041024 - RJL]
---------------------------------

The predecessor of this doc, ../04s522/04s522LCPupdateProjects.txt,
and the docs in 04s522/ajlopez/lcp, describe the recent 
enhancement to LCP: auto-generating an indexed array of Action 
routine addresses and executing the action from its index stored
in STcurr->ActFunc. 

The above design choices are not optimal, but they reduced
the scope of this 04s522 project. They suffice 
to update LCP so pointer-based function tables can be 
declared, generated automatically and invoked efficiently
from LCP for any data model.

This note describes three other follow-on LCP projects:
	1. Generalizaion of ActFunc indexed array (FuncTbl) access
	2. Guard COndition code generation for LCP:


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


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


3. TimedEventQueManager 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/<usernames>
These were parallel projects. Neither was completed.

Their goal was to replace all Timer Active Instances 
by a Timed-Event (priority) queue, with a single 
TimedEventrQueManager service that runs under the LCP event
dispatcher. This service accepts events on behalf of TImers,
and sorts them into future time_is_up order and enqueues
them. It also checks the head of this queue and converts 
expired timeout events to regular reply or callback events 
on the Event Instance que.

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