Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #5642 > unrolled thread

calling tool version function outside the the normal calling

Back to article view | Back to comp.sys.apple2.programmer

Contents

  calling tool version function outside the the normal calling Chris Vavruska <vavruska@gmail.com> - 2020-07-17 09:41 -0700
    Re: calling tool version function outside the the normal calling Steven Hirsch <snhirsch@gmail.com> - 2020-07-17 13:34 -0400
      Re: calling tool version function outside the the normal calling Chris Vavruska <vavruska@gmail.com> - 2020-07-17 11:04 -0700
        Re: calling tool version function outside the the normal calling Steven Hirsch <snhirsch@gmail.com> - 2020-07-17 14:46 -0400
          Re: calling tool version function outside the the normal calling "vavr...@gmail.com" <vavruska@gmail.com> - 2020-07-17 12:15 -0700
    Re: calling tool version function outside the the normal calling Stephen Heumann <stephen.heumann@gmail.com> - 2020-07-17 19:08 -0500
    Re: calling tool version function outside the the normal calling Chris Vavruska <vavruska@gmail.com> - 2020-07-17 17:45 -0700
      Re: calling tool version function outside the the normal calling Stephen Heumann <stephen.heumann@gmail.com> - 2020-07-17 20:07 -0500
    Re: calling tool version function outside the the normal calling Chris Vavruska <vavruska@gmail.com> - 2020-07-17 19:16 -0700
    Re: calling tool version function outside the the normal calling kelvin@pro-kegs.uucp (Kelvin Sherlock) - 2020-07-18 02:19 -0500
      Re: calling tool version function outside the the normal calling Stephen Heumann <stephen.heumann@gmail.com> - 2020-07-17 22:14 -0500
        Re: calling tool version function outside the the normal calling Chris Vavruska <vavruska@gmail.com> - 2020-07-18 05:19 -0700

#5642 — calling tool version function outside the the normal calling

I am trying to load up a tool outside of LoadOneTool/ToolStartUp to get the version of the tool.  The following code always returns zero. put a BRK in it to trace into the function call and it appears it is calling the right function but something on the return stack is being messed up and the value is set to zero. My assembly skills are non existent so if anyone has some pointers I'd appreciate it.

word getToolVersion(GSString255Ptr path) {
    InitialLoadOutputRec loadInfo;
    word userID;
    WordProcPtr getVer;
    ptr *funcs;
    word toolVersion;

    userID = GetNewID(0x5000);
    loadInfo = InitialLoad2(userID, (ptr) path, 1, 1);
    funcs = (ptr*) (loadInfo.startAddr);
    getVer = (WordProcPtr*) (funcs[4]+1);
    toolVersion = getVer();

    DisposeAll(userID);
    DeleteID(userID);

    return toolVersion;
}

[toc] | [next] | [standalone]

#5643

On 7/17/20 12:41 PM, Chris Vavruska wrote:
> I am trying to load up a tool outside of LoadOneTool/ToolStartUp to get the
> version of the tool.  The following code always returns zero. put a BRK in
> it to trace into the function call and it appears it is calling the right
> function but something on the return stack is being messed up and the value
> is set to zero. My assembly skills are non existent so if anyone has some
> pointers I'd appreciate it.
> 
> word getToolVersion(GSString255Ptr path) { InitialLoadOutputRec loadInfo; 
> word userID; WordProcPtr getVer; ptr *funcs; word toolVersion;
> 
> userID = GetNewID(0x5000); loadInfo = InitialLoad2(userID, (ptr) path, 1,
> 1); funcs = (ptr*) (loadInfo.startAddr); getVer = (WordProcPtr*)
> (funcs[4]+1); toolVersion = getVer();
> 
> DisposeAll(userID); DeleteID(userID);
> 
> return toolVersion; }
> 

What happens when you query the version inside the LoadOneTool/ToolStartUp 
environment?

[toc] | [prev] | [next] | [standalone]

#5644

On Friday, July 17, 2020 at 1:34:19 PM UTC-4, Steven Hirsch wrote:
> On 7/17/20 12:41 PM, Chris Vavruska wrote:
> > I am trying to load up a tool outside of LoadOneTool/ToolStartUp to get the
> > version of the tool.  The following code always returns zero. put a BRK in
> > it to trace into the function call and it appears it is calling the right
> > function but something on the return stack is being messed up and the value
> > is set to zero. My assembly skills are non existent so if anyone has some
> > pointers I'd appreciate it.
> > 
> > word getToolVersion(GSString255Ptr path) { InitialLoadOutputRec loadInfo; 
> > word userID; WordProcPtr getVer; ptr *funcs; word toolVersion;
> > 
> > userID = GetNewID(0x5000); loadInfo = InitialLoad2(userID, (ptr) path, 1,
> > 1); funcs = (ptr*) (loadInfo.startAddr); getVer = (WordProcPtr*)
> > (funcs[4]+1); toolVersion = getVer();
> > 
> > DisposeAll(userID); DeleteID(userID);
> > 
> > return toolVersion; }
> > 
> 
> What happens when you query the version inside the LoadOneTool/ToolStartUp 
> environment?

Good question....quickly verifies...It returns the correct version.

[toc] | [prev] | [next] | [standalone]

#5645

On 7/17/20 2:04 PM, Chris Vavruska wrote:
> On Friday, July 17, 2020 at 1:34:19 PM UTC-4, Steven Hirsch wrote:
>> On 7/17/20 12:41 PM, Chris Vavruska wrote:
>>> I am trying to load up a tool outside of LoadOneTool/ToolStartUp to get the
>>> version of the tool.  The following code always returns zero. put a BRK in
>>> it to trace into the function call and it appears it is calling the right
>>> function but something on the return stack is being messed up and the value
>>> is set to zero. My assembly skills are non existent so if anyone has some
>>> pointers I'd appreciate it.
>>>
>>> word getToolVersion(GSString255Ptr path) { InitialLoadOutputRec loadInfo;
>>> word userID; WordProcPtr getVer; ptr *funcs; word toolVersion;
>>>
>>> userID = GetNewID(0x5000); loadInfo = InitialLoad2(userID, (ptr) path, 1,
>>> 1); funcs = (ptr*) (loadInfo.startAddr); getVer = (WordProcPtr*)
>>> (funcs[4]+1); toolVersion = getVer();
>>>
>>> DisposeAll(userID); DeleteID(userID);
>>>
>>> return toolVersion; }
>>>
>>
>> What happens when you query the version inside the LoadOneTool/ToolStartUp
>> environment?
> 
> Good question....quickly verifies...It returns the correct version.

Is there any reason you cannot query versions at initial load and cache them 
if needed later?

[toc] | [prev] | [next] | [standalone]

#5646

On Friday, July 17, 2020 at 2:46:33 PM UTC-4, Steven Hirsch wrote:
> On 7/17/20 2:04 PM, Chris Vavruska wrote: 
> > On Friday, July 17, 2020 at 1:34:19 PM UTC-4, Steven Hirsch wrote: 
> >> On 7/17/20 12:41 PM, Chris Vavruska wrote: 
> >>> I am trying to load up a tool outside of LoadOneTool/ToolStartUp to get the 
> >>> version of the tool. The following code always returns zero. put a BRK in 
> >>> it to trace into the function call and it appears it is calling the right 
> >>> function but something on the return stack is being messed up and the value 
> >>> is set to zero. My assembly skills are non existent so if anyone has some 
> >>> pointers I'd appreciate it. 
> >>> 
> >>> word getToolVersion(GSString255Ptr path) { InitialLoadOutputRec loadInfo; 
> >>> word userID; WordProcPtr getVer; ptr *funcs; word toolVersion; 
> >>> 
> >>> userID = GetNewID(0x5000); loadInfo = InitialLoad2(userID, (ptr) path, 1, 
> >>> 1); funcs = (ptr*) (loadInfo.startAddr); getVer = (WordProcPtr*) 
> >>> (funcs[4]+1); toolVersion = getVer(); 
> >>> 
> >>> DisposeAll(userID); DeleteID(userID); 
> >>> 
> >>> return toolVersion; } 
> >>> 
> >> 
> >> What happens when you query the version inside the LoadOneTool/ToolStartUp 
> >> environment? 
> > 
> > Good question....quickly verifies...It returns the correct version.
> Is there any reason you cannot query versions at initial load and cache them 
> if needed later?
The application may or may not already have another version of the tool already loaded. I want to be able to compare the versions of two tool files.

[toc] | [prev] | [next] | [standalone]

#5647

On 2020-07-17 16:41:47 +0000, Chris Vavruska said:

> I am trying to load up a tool outside of LoadOneTool/ToolStartUp to get 
> the version of the tool.  The following code always returns zero. put a 
> BRK in it to trace into the function call and it appears it is calling 
> the right function but something on the return stack is being messed up 
> and the value is set to zero. My assembly skills are non existent so if 
> anyone has some pointers I'd appreciate it.

Your code is trying to call the tool's version call using the ORCA 
calling convention, which is different from the calling convention for 
tool calls.  I think you'll need to use at least some assembly language 
to call it properly.  Here's a version using inline assembly that I 
think should work:

word getToolVersion(GSString255Ptr path) {
    InitialLoadOutputRec loadInfo;
    word userID;
    WordProcPtr getVerMinus1;
    ptr *funcs;
    word toolVersion = 0;

    userID = GetNewID(0x5000);
    loadInfo = InitialLoad2(userID, (ptr) path, 1, 1);
    funcs = (ptr*) (loadInfo.startAddr);
    getVerMinus1 = (WordProcPtr*) (funcs[4]);

    asm {
        pea 0x0000          //result space
        phk                 //extra return address space (not used)
        pea ret-1
        phk                 //return address
        pea ret-1
        sep #0x20           //address to call (minus 1)
        lda getVerMinus1+2
        pha
        rep #0x20
        pei getVerMinus1
        rtl                 //call it
ret:    phk                 //clean up stack
        pla
        pla
        pla                 //get return value
        sta toolVersion
    }

    DisposeAll(userID);
    DeleteID(userID);

    return toolVersion;
}

-- 
Stephen Heumann

[toc] | [prev] | [next] | [standalone]

#5648

On Friday, July 17, 2020 at 12:41:48 PM UTC-4, Chris Vavruska wrote:
> I am trying to load up a tool outside of LoadOneTool/ToolStartUp to get the version of the tool.  The following code always returns zero. put a BRK in it to trace into the function call and it appears it is calling the right function but something on the return stack is being messed up and the value is set to zero. My assembly skills are non existent so if anyone has some pointers I'd appreciate it.
> 
> word getToolVersion(GSString255Ptr path) {
>     InitialLoadOutputRec loadInfo;
>     word userID;
>     WordProcPtr getVer;
>     ptr *funcs;
>     word toolVersion;
> 
>     userID = GetNewID(0x5000);
>     loadInfo = InitialLoad2(userID, (ptr) path, 1, 1);
>     funcs = (ptr*) (loadInfo.startAddr);
>     getVer = (WordProcPtr*) (funcs[4]+1);
>     toolVersion = getVer();
> 
>     DisposeAll(userID);
>     DeleteID(userID);
> 
>     return toolVersion;
> }
Hi Stephen,

thanks for the code. Getting the following trying to compile.

 134         phk                 //return address
             ^ invalid operand
 136         sep #0x20           //address to call (minus 1)
             ^ invalid operand

[toc] | [prev] | [next] | [standalone]

#5649

On 2020-07-18 00:45:46 +0000, Chris Vavruska said:
> Hi Stephen,
> 
> thanks for the code. Getting the following trying to compile.
> 
>  134         phk                 //return address
>              ^ invalid operand
>  136         sep #0x20           //address to call (minus 1)
>              ^ invalid operand

It looks like the assembler in ORCA/C isn't accepting the operand 
"ret-1" (on the lines above the ones shown).  I think it should accept 
them, but if it doesn't you could move the "ret:" label up a line (to 
the rtl), and then change both of those operands to just "ret".

-- 
Stephen Heumann

[toc] | [prev] | [next] | [standalone]

#5650

On Friday, July 17, 2020 at 12:41:48 PM UTC-4, Chris Vavruska wrote:
> I am trying to load up a tool outside of LoadOneTool/ToolStartUp to get the version of the tool.  The following code always returns zero. put a BRK in it to trace into the function call and it appears it is calling the right function but something on the return stack is being messed up and the value is set to zero. My assembly skills are non existent so if anyone has some pointers I'd appreciate it.
> 
> word getToolVersion(GSString255Ptr path) {
>     InitialLoadOutputRec loadInfo;
>     word userID;
>     WordProcPtr getVer;
>     ptr *funcs;
>     word toolVersion;
> 
>     userID = GetNewID(0x5000);
>     loadInfo = InitialLoad2(userID, (ptr) path, 1, 1);
>     funcs = (ptr*) (loadInfo.startAddr);
>     getVer = (WordProcPtr*) (funcs[4]+1);
>     toolVersion = getVer();
> 
>     DisposeAll(userID);
>     DeleteID(userID);
> 
>     return toolVersion;
> }

I had tried that. It does not like pushing the label.

[toc] | [prev] | [next] | [standalone]

#5651

Stephen gave the proper way to do it but the quick and easy (and
disgusting) thing to do is:

  asm { pha }
  getVer();
  asm { pla sta toolVersion }

-------
ProLine: kelvin@pro-kegs

[toc] | [prev] | [next] | [standalone]

#5652

On 2020-07-18 02:19:51 +0000, Kelvin Sherlock said:

>   asm { pha }
>   getVer();
>   asm { pla sta toolVersion }

I don't think that will quite work, because Chris is trying to call a 
tool call without using the tool dispatcher, so it is expecting space 
on the stack for an extra return address.  If you push/pull three extra 
bytes to account for that, this approach may work, but it's a hack.

Chris, I tried the code I posted and it worked, so I'm not sure why 
it's giving you problems (maybe issues with line endings?), but an 
alternative is to replace the "pea ret-1" instructions with:

lda	#ret-1  // or "lda #ret", if you changed the label location
pha

-- 
Stephen Heumann

[toc] | [prev] | [next] | [standalone]

#5653

On Friday, July 17, 2020 at 11:14:42 PM UTC-4, Stephen Heumann wrote:
> On 2020-07-18 02:19:51 +0000, Kelvin Sherlock said:
> 
> >   asm { pha }
> >   getVer();
> >   asm { pla sta toolVersion }
> 
> I don't think that will quite work, because Chris is trying to call a 
> tool call without using the tool dispatcher, so it is expecting space 
> on the stack for an extra return address.  If you push/pull three extra 
> bytes to account for that, this approach may work, but it's a hack.
> 
> Chris, I tried the code I posted and it worked, so I'm not sure why 
> it's giving you problems (maybe issues with line endings?), but an 
> alternative is to replace the "pea ret-1" instructions with:
> 
> lda	#ret-1  // or "lda #ret", if you changed the label location
> pha
> 
> -- 
> Stephen Heumann

That did it. Thank you so much.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web