~lechner/public_html/04f522/stateModelIndexedFcnPtrArray.040913 

(rev.040913 by RJL; summarizes work by AJLopez in 04s522)

In a reply to elalo on 040317 (cc to 04s522)
I said t2b.c ought to work independent
of machine pointer size (Linux or alpha machines).
LCP state model interpretation will be another story:


Genv12 and the state table schema do not have a pointer 
field data type. Therefore  state action (function) pointer 
fields must be initialized by the linker, not chgen,
in a place where the state table can access them somehow.

Independent state [sub-]models (STD's) may exist 
for more than one method of the same class. Address pointers 
are needed for the LCP interpreter to execute the atomic 
action routine of each state in each STD methoa.
These should be declared in a class-specific table  that spans 
multiple State Models.
This table must include a platform-specific pointer data field, 
which must be linker-initialized because chgen does not support
an address poiner data type.


My long-range goal is to extend genv12 to generate this function
poinr array by reading and interpreting the State Model database.  
This database is analogous to schema.msdat  which holds schema 
table and attribute definitions. It can either be initialized 
by olcarch setup procedures or by using bde2SM 
which converts bde diagrams into State Models. 
However, extending genv12 is not necessary while
LCP remains an interpreter instead of a code generator. 
Instead a new module has been added to the olcarch library
by AJLOpez in 04s522 which works for any gen-based application.

The generated code declares a single indexed function 
poiner array that accumulates function pointers from all STD's
that are defined in XXsetup or XXops procedures, where XX is a 
struct or class type tag for each table type 
declared in the application's schema.sch file. 
that inherits from an Active Class.
Lopez's module is called from the StateModelCreateCompletely 
routine of olc, which writes the State Model database.
The index of a particular action of any  state in table ST 
is globally unique over all state models in parent table SM.

The dotransition routine of the olcarch library calls the action 
routine of a state by using the existing ActionRoutinePtr 
or ActFunc field of table ST as an index into this array. 
The array itself is declared in a .h file that is #included 
in the application source code or its schema.h; the linker
will initialize its pointer values when it links the executable.


04s522 LCPupdate Project by ajlopez:	(added by RJL 040523)
========================================

In A J Lopez' project in 04s522, the function pointer (I4 type) field 
STcurr-> ActRtn is replaced by a 32-bit integer index (chgen attribute 
value type i4). At the same time the ActRtn poiner is defined in  
a FuncPtr array that is #included in run phase source code files. 
This array is generated by the setup routines in the olcarch SM 
interpreter code library. The index is referenced as STcurr->ActRtnIndex
and the function call becomes (*(STcurr->ActRtnIndex(EIcurr))).
(EIcurr points to the ActRTn's argument list in the EventInstance 
that caused the state transition, in the EI table or queue.)

(This necessitates a change in the build process: the setup phase 
must be executed, not just compiled, before the main simulation 
or run phase is compiled, so the linker can find the addresses 
in object files to assign to pointer array locations.
The ActRtn field name in table ST is retained for backward compatibility. 
Renaming it would require recompiling all LCP-based applications.)



This approach is also compatible with two enhanced versions 
of the State Model schema: Both of these access the function pointer
array by means of an index in function table FT instead of table ST:

(1) Table FT has a 1-to-many relation to table ST:
Then each STate has an FTid fkey to  its 'parent' row 
in table FT.  The latter row contains the ActRtnIndex value.
This index can be accessed from the ST table as 
	STcurr->FTid_pp->ActRtnIndex.
The olc/src/doTransition function invokes the state action by
	(&(STcurr->FTid_pp->FuncPtrIndex)).

(2) A many-to-many association table SF  relates table ST to FT: 
One state action can define a sequence of function calls.
Then a child_loop(ST, SF, SFid, STid) can access a sequence 
of function pointers in a chld_loop from ST to SF: 
Each function index is SFcurr->FTid_pp->ActRtnIndex.
The olc/src/doTransition function invokes each function by
	(&(SFcurr->FTid_pp->FuncPtrIndex)) for each SF child of ST.

[Incidentally, Chapter 6 of a recent text by Miro Samek
(Practical Statecharts in C/C++, CMP Books2002) 
discusses ways in which references to superclass virtual functions 
are bound at link time to override methods in each of its subclasses.]

File