|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.