Oppolzer - Informatik / Blog

Hello Don,

well, pretty nice. I like this approach very much. One difference to our
approach could be, that we don't need an explicit call to the loader from the
parent module; the LOAD is done by the stub only the first time, when the
statically stored entry point is zero. But I can imagine some kind of mixture
between the two approaches, where the loader is called by the stub, if the
entry point is zero. Then also no special loader call would be necessary.

In our approach, indeed, the caller goes to the switch in front of the DLL
module every time. But if the module is already loaded, this makes only circa
10 additional machine instructions. Maybe we could optimize this further, using
your ideas.

On the other hand, maybe it is nice to have a special INIT call for such DLL
like modules. We don't need it, because all our modules MUST be
naturally reentrant, so we cannot store information statically. If we need some
initialization, we have to do it every time. The only exception: the entry
points are stored statically, as explained.

One problem remains with all these solutions: IBM has slightly modified the
conventions for new PL/1, C++ and so on. The entry point alone is not
sufficient; you also have to worry about the base address of the writable
static storage. Reg 15 doesn't point to the real entry any more, but to some
kind of control block, where the real entry and the base for the writable
static is stored (with some "glue" code). At the moment, we use only old PL/1
and ANSI C without the RENT or DLL option, so this is not an issue.

Would your solution also work with calls to or from RENT and DLL objects ?
I guess, our solution will not work "as is".

Regards

Bernd



Am Die, 05 Nov 2002 schrieben Sie:
>
> Interesting.  The caller always goes to the DLL like module, but the called
> function returns to the parent caller.  We have done something similar to
> this, but it one more step removed from being DLL like relationship.  At our
> site, the parent module calls a loader with the name of the desired function
> (a module, also.)  The loader loads the function into core and stores its
> load address back into the parent caller.  The loader than branches to the
> called function so it can do its first time initialization.  The called
> function returns to the parent caller.  The parent module now branches
> directly to the called function because it has the load address (provided by
> the loader.)
>
> A middle man assists the caller but then gets out of the way.