Re: iseries pgm call support

Bob Donovan,

Here are some details of my module call proposal.

In your response, you mentioned data addressability and module resolving as
details to be addressed.

Other details I would add to the list:
    Global variables
    Exception handling
    Module in use determination
    Dynamic resolving to modules with the same name but different argument
types. ( function overloading ) ( esp if a best fit rather than exact fit is
accepted )

Another detail which rochester itself has put off is "Object resolution
perspective". That is, when a module resolves to another module, does it
resolve from the perspective of the job ( library list ) or from the
perspective of the calling module ( search first the lib of the caller, then
search the libl of the job ).
This detail spawns a requirement that a library itself needs to be able to
contain libraries ...  that is libraries should be like directories.

Let me focus on what I would name a module machine call. The objective is to
describe the minimum that the machine would have to provide to support a
jump/call to code in an external executable object.  Here is the code:

In the calling pgm/module:

    DCL SYSPTR   pModuleObject ;
    DCL INSPTR   pModule,   pRtnIp ;
    DCL DD            cData  CHAR(80)  AUTO ;
    DCL SPCPTR  pModuleStackEntry  AUTO ;
    DCL SPCPTR  pData  Bas(pModuleStackEntry)  Pos(33) ;

    RSLVSP           pModuleObject,  "module name" ;
    SetIpFp             pModule,   pModuleObject ; /* set ip from ptr */

/* push onto the module call stack. push size is found in module obj defn.
*/
    ModPush          pModule,  pModuleStackEntry ;

    SetSpp              pData, cData ;   /* data to pass to module */
    ModCall            pModule,  pModuleStackEntry   /* call module */

In the called module:
    DCL SPC         Local   BASPCO  Pos(160001) ;
    DCL INSPTR    pRtnIp  Def(Local)  Pos(1) ;
    DCL SPCPTR pThis  Def(Local)  Pos(17) ;
    DCL SPCPTR pData  Def(Local)  Pos(33) ;
    DCL DD           Data  Char(80)  Bas(pData) ;
    DCL DD           ch80  Char(80)  Def(Local)  Pos(65) ;

    ModEntry          512 ;     /* module entry. 512 = stack entry size. */
    CPYBLA          ch80,  Data ;  /* copy callers data into local variable.
*/
    ModReturn       pRtnIp ;     /* return from the module. */

What the machine provides:
    A module call stack for each pgm invocation.
    A more visible exception monitor table.
    Maintains pointers in the PCO to the
        Current pgm invocation call stack.
        Current call stack entry in the current call stack.
    ModCall, ModPush, ModEntry, ModReturn instructions.

Exception handling. A module needs access to the exception handling table of
the pgm invocation. The machine should provide addressability to this table.
A ptr in the PCO of the job might work.  When an exception occurs, there are
data addressing and call stack unrolling details to be addressed.

Stack support. The machine provides at least the minimum necessary.
    Each pgm invocation has a module call stack.
    A ptr in the pco of the job contains a ptr to the current module call
stack entry.
    ModPush pushes onto the stack.
    ModReturn pops from the stack.

When you consider the details of the call and deal with the transition from
the dft addressability of the calling module to the called module .....  a 2
step call process is needed.
    ModPush     pModule, pModuleCallStackEntry ;
/* copy arguments to the called modules call stack entry space.  */
    CallMod       pModule, pModuleCallStackEntry ;

The module object contains its stack entry and  local data size
requirements. ModPush and ModReturn will reference this value when
allocating call stack space.

There are also considerations needed to account for when transitioning back
from the called to the calling module. The calling module needs to access
the space of the just popped called module stack entry in order to copy
return arguments.

More details off the top of my head provided upon request<g>.

Is this needed? Does the current pgm and ile function call support provide
all that appl developers need? Maybe that question does not have to be
answered directly.

Maybe the decision to implement can be guided by the principle that
primitives, like basic research provide unforseen future benefits. The
decision to implement can then be based on the non negative impact of the
primitive ( does it break other parts of the machine, does it make the
machine harder to maintain ) rather than its benefits that are obvious to
some but not to others.

One benefit: System object ( file, dtaara ) member functions like copy,
construct and destruct may be best implemented by the standalone,
dynamically resolved to code module.


Steve Richter
July 13, 2001




+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---