RE: [MiNT] Proposal for SLB extension

["Julian Reschke" <reschke@muenster.de>]

> From: owner-mint@fishpool.com [mailto:owner-mint@fishpool.com]On Behalf
> Of Jörg Westheide
> Sent: Thursday, April 06, 2000 7:49 PM
> To: mint@fishpool.com
> Subject: [MiNT] Proposal for SLB extension
>
>
> Hi Julian!
>
> JW>The backdraw of your proposal is that you have to check wheter the
> JW>basepage pointer is needed at run time. So your code has to deal with
> JW>both possibilities.
> JR>Not true. He could just simply supply two different function call
> JR>handlers.
> Which is one kind of dealing with this problem

Yes. So? It solves the problem with no run-time overhead for fucntion calls.

> JW>And if there are two different implementation of the same lib you will
> JW>run into trouble.
> JR>Why would this be a problem.
> The (not clearly stated) context was that the application
> supports only one
> kind of libraries

No, it wasn't.

> But think a little bit of the expense of supporting two handlers:
> The fastest way I know is to decide which one to use an then saving the
> address of the used one in an variable and then letting the stub called by
> the application make a jump to the content of this variable.

No, you just return the pointer to the right handler upon Slbopen(). This is
*once* per SLB load per process.

> In asm:
>
> stub:
>     move.l used_handler, a0
>     jmp (a0)
>
> Can someone tell me why this should be faster than
>
>     move.l basepage, -(sp)

This can't be used, because there is no variable "basepage" to which the
function call handler would have access to.

> (as I don't know the interface for shared lib calls I assume the
> parameter is
> passed on the stack, which is slower than the passing in a register)

How about reading the SLB spec before continuing this discussion? :-)

> AFAIK both need 28 cycles (on 68000), but the first one needs more memory
> than the second and I haven't counted the memory for the second handler
>
> So, where is the advantage of not passing the basepage address?

Because it's not a matter of 28 cycles, but of at least one GEMDOS trap *per
single SLB function call*.