RE: iseries pgm call support

Interesting concept w.r.t. external call..

Perhaps our answer is a new object called an "Application Entry Point Table"
modeled after the system entry point table.

A simple SVC call referencing the Application ID and the External Module ID
could work.
Parameter passage could match the standards used in what I remember was the
ICB...

All we need are some commands to manage the Application Entry Point Table
and we can get some serious speed. For example, CRTAEPT, DLTAEPT, ADDAEPTE
(Add an entry), RMVAEPTE, etc.

A code will be needed in a program header to indicate that it is referenced
in one or more of these great tables. Need to consider save/restore issues
w.r.t. the tables as well as compiles that alter the actual address.

Heck, PTFs have been altering INSEPT for a while. I even remember a "C"
program doing it by mistake!
Why not have a user level table that could speed up the calls.

JMHO

Steve Glanstein
mic@aloha.com

> -----Original Message-----
> From: owner-mi400@midrange.com [mailto:owner-mi400@midrange.com]On
> Behalf Of Bob Donovan
> Sent: Thursday, July 12, 2001 5:09 PM
> To: MI400@midrange.com
> Subject: Re: iseries pgm call support
>
>
>
> On 07/12/2001 at 11:59:43 AM, steve richter wrote:
>
>      Here is my list of iseries architecture features that  Rochester is
> failing to exploit:
>
> 1. External module call. Single level store enables a running  pgm to jump
> to code in an external object/module. This jump can execute as  quickly as
> jumping to code within the pgm itself. Would enable true
> modularization of
> the code of an application.
>
> Not provided so as not to detract from the ile model  monster.  ile must
> exist so the iseries can mimic lesser platforms that the  iseries is
> striving to be compatible with.
>
> Steve,
>
> The devil is in the details.  As I understand your proposal, I
> see a number
> of technical details that must be addressed to make this feature
> usable and
> robust.  Here are some things that come to mind:
>
> o The proposal must address register usage.  What rules will you
> define for
> register usage across the transfer of control?  If the external module
> needs to use registers n through m, will the called module save
> and restore
> them?  If so, where (such that the code is reentrant)?  Will these
> conventions coexist with other programs on the system?  For example, can I
> call off to existing runtime library functions?
>
> o Will you allow passing parameters to the external modules?  How?
>
> o What mechanism will you use for returning to your caller?
>
> o How do the caller's obtain the address of the external module?   What if
> I need to change the external module ... will all of the caller's be
> updated with the new address (even if they are currently running)?
>
> o Can external modules define data?  If so, explain how you might support
> static or automatic variables.
>
> As you address these details, I think you might come up with
> something that
> is pretty similar to the existing mechanisms for transferring control
> between code e.g., dynamic program calls and static binding).  If
> not, then
> I would agree that Roch needs to take a closer look.
>
> - Bob Donovan  rjd@us.ibm.com
>
>
>
> +---
> | 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
> +---
>

+---
| 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
+---