Does CLEAR Command clear return adrress of a subroutine?

Printable View

- 5th February 2008, 11:07
sayzer

Does CLEAR Command clear return adrress of a subroutine?

Hi there,

Does CLEAR command clear the return address of a subroutine on the stack ?

Thanks.

===============================
- 5th February 2008, 12:15
paul borgmeier

No - the stack space is not part of the data space. Just your defined variables and PBP (internal) defined variables are cleared.
- 8th February 2008, 19:25
sayzer

Thanks Paul.

Other then hard reset, how do I clear return adresses?
- 8th February 2008, 19:32
skimask

Quote:

Originally Posted by sayzer

Thanks Paul.

Other then hard reset, how do I clear return adresses?

I haven't tried it myself...but...
Looking thru the datasheet for the 18F4620, I see:
TOSU, TOSH, TOSL (top of stack, upper, high, low) and the STKPTR register. Looks like the contents of STKPTR are Read/Write. So, in theory, you should be able to decrement the value in the low 5 bits of STKPTR and thereby 'POP' the last 'PUSH' off the stack.
- 9th February 2008, 05:48
paul borgmeier

SAYZER,

On 16 bit devices (e.g., 18F), you can reset the STKPTR = 0 to "clear" all the addresses on the stack. The values really are not cleared - but the stack pointer points to the first location (0) and does not know about the "old" values. You could actually clear them if you wanted as Ski noted but the pointer tells the PIC where to place and get stack data.

On 14 or lesser bit devices (e.g., 16F or lesser), you cannot clear the Stack (it is a circular buffer and does not reside in program or data space).

NOTE: you must be very careful messing with the Stack because behind the scenes, PBP uses it!
- 9th February 2008, 06:45
skimask

Quote:

Originally Posted by paul borgmeier

On 14 or lesser bit devices (e.g., 16F or lesser), you cannot clear the Stack (it is a circular buffer and does not reside in program or data space).

I'd almost bet money that there's an undocumented instruction that handles POP's on the 14 bit types...but you'd figure somebody would've found it by now.
- 9th February 2008, 09:02
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
- 9th February 2008, 14:21
paul borgmeier

Quote:

Originally Posted by Acetronics

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?
- 9th February 2008, 16:56
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
- 10th February 2008, 13:39
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.

-------------------
- 11th February 2008, 03:15
skimask

Quote:

Originally Posted by 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.
-------------------

How about something like this:

Code:

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...
- 11th February 2008, 05:58
paul borgmeier

Quote:

Originally Posted by sayzer

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.
- 12th February 2008, 10:04
sayzer

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

I am having a lot of return addresses.
_________________________________
- 19th February 2008, 15:28
sayzer

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

Code:

Begin: OK = 0 MainMenu: '...stuff is going on here... IF OK = 1 THEN GOSUB PrintMemory GOTO MainMenu PrintMemory: IF Memory = 0 THEN Begin RETURN ' IF this IF statement is true, then I get a useless Return address on Stack, and I get a lot of them.
- 19th February 2008, 16:25
skimask

Quote:

Originally Posted by sayzer

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

If you're careful, and I mean very, very careful, you could turn off the Stack Overflow/Underflow reset bits in the CONFIG and just not worry about the RETURN addresses...let them overflow as they will.
But again, you'd have to be very careful, especially if you nest any GOSUB's at all...so that might not work out at all.
Maybe take DT's Software Gosub example shown earlier and add your own subroutine to POP the last GOSUB address off the Software Stack.

Actually, I just looked at the code for the first time...
In the swStack.inc file, you could use this section:

Code:

'------------Pop Address from the Stack--------------------------------------- Pop: if StackPTR = 0 then StackEmpty = 1 ; Update Empty status if StackEmpty = 0 then ; If Stack isn't Empty Address = Stack[StackPTR-1] ; Get last Address from the Stack StackPTR = StackPTR - 1 ; Point to Prior Stack level StackFull = 0 ; 0 - Since we just removed 1 else STunderflow = 1 ; Stack was Empty on swReturn endif if StackPTR = 0 then StackEmpty = 1 ; Update Empty status return

You have access to the Pop subroutine.

But I'm guessing here...since I haven't used to swGosub/swReturn routines at all.........

You 'include' DT's software stack routines, your code above becomes:

Code:

Begin: OK = 0 MainMenu: '...stuff is going on here... IF OK = 1 THEN @ swGOSUB PrintMemory ENDIF GOTO MainMenu PrintMemory: IF Memory = 0 THEN Gosub Pop 'regular Gosub here, generic, can be used system wide Goto BEGIN 'no more return address from the Gosub above ENDIF swRETURN

Again, I'm guessing...