Does CLEAR Command clear return adrress of a subroutine?

[Acetronics2]

Hi, Sayzer

I didn't look at it very closely ...

but I feel you can find your solution Here :

http://www.pbpgroup.com/modules/wfse...p?articleid=14

and once more ...

Thanks to Whom ????

D.A.R.R.E.L. !!!! ..........

Alain

[paul borgmeier]

Hi, Sayzer

I didn't look at it very closely ...

but I feel you can find your solution Here :

http://www.pbpgroup.com/modules/wfse...p?articleid=14

and once more ...

Thanks to Whom ????

D.A.R.R.E.L. !!!! ..........

Alain

Darrel's clever method for the 16F type PICs creates a software stack - the real "stack" is not in program or data space and cannot be accessed (unless there is a back door that nobody knows about as Ski suggested)

I guess that SAYZER could create a software stack (as Alain is suggesting) and then manipulate it as needed? SAYZER, what are you trying to do and with what family of PIC?

[Acetronics2]

Hi, Paul

There's also something Doable ( depends on use ...) :


A GOSUB loads an address you can choose in the stack ...

if ending the SUB with a GOTO instead of a RETURN ... This address will stay as the new "return", "retfie" ... address.

That's used with the "RESUME Label" of PbP ...

I do not think "clearing" the stack would be really useful ... as a stack containing zeros will cause the device to reset ONLY its program on the first "return or so" met ...

Alain

[sayzer]

As Alain mentioned, there are potential side effects If I start playing directly with the registers.

Instead now, I am using flags being set to zero before going to a subroutine, and set the flags if something inside the subroutine is used.

Then at the end of the subroutine(s), I am using a kind of select case with "GOTO".

This way, I don't have any "return" address to care for.


This is a little code eating though; but a lot safer.

-------------------

[skimask]

As Alain mentioned, there are potential side effects If I start playing directly with the registers.
Instead now, I am using flags being set to zero before going to a subroutine, and set the flags if something inside the subroutine is used.
Then at the end of the subroutine(s), I am using a kind of select case with "GOTO".
This way, I don't have any "return" address to care for.
This is a little code eating though; but a lot safer.
-------------------

How about something like this:

main:
code....code...code...
addrreturn = 1
goto subroutine

return1:
addrreturn = 2
goto subroutine

return2:
addrreturn = 0
goto main

subroutine:
code....code....code
branch addrreturn , [ return1 , return2, return3.................]

Set your branch return location parameter, jump to the generic subroutine, branch back to wherever it came from. No calls, no gosubs, and so on...

[paul borgmeier]

Instead now, I am using flags being set to zero before going to a subroutine, and set the flags if something inside the subroutine is used.

Then at the end of the subroutine(s), I am using a kind of select case with "GOTO".

This way, I don't have any "return" address to care for.

Hi SAYZER,

I do not get what you mean by "return" address care ... why can't you just match each "gosub" with a "return" and let PBP do the work.

[sayzer]

In the code, I jump from locations to locations really very fequently.

I am having a lot of return addresses.
_________________________________

[sayzer]

Ok, here is a simple example good enough to explain the issue.

<font color="#000000">Begin:

OK = <font color="#FF0000"><b>0


</b></font>MainMenu:
<font color="#000080"><i>'...stuff is going on here...

    </i><b>IF </b></font>OK = <font color="#FF0000"><b>1 </b></font><font color="#000080"><b>THEN GOSUB </b></font>PrintMemory


    <font color="#000080"><b>GOTO </b></font>MainMenu
    
    
PrintMemory:
    <font color="#000080"><b>IF </b></font>Memory = <font color="#FF0000"><b>0 </b></font><font color="#000080"><b>THEN </b></font>Begin
    <font color="#000080"><b>RETURN    </b>
<i>' IF this IF statement is true, then I get a useless Return address on Stack,
and I get a lot of them.
</i></font>