Searching \ for '[PIC]: Stack Overflows' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Stack Overflows'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Stack Overflows'
2001\01\25@130710 by Andy N1YEW

picon face
Is there a problem if my code overflows the stack?
like if in the delay i poll some lines and call a function if the lines are in a certain state.
The delay wont matter.  it is trivial.
but if the stack overflows (ie the delay poll call a function which does the same delay routine and call another, and on till the stack overflows.) what happens?
does it reset the stack? (empty it like)
would it matter?
Thanks,
Andy N1YEW
btw this is using an f84 for a PL board controller....

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body


2001\01\25@140450 by Olin Lathrop

face picon face
> Is there a problem if my code overflows the stack?

No, a stack is just one of those silly frills Microchip puts in there to
justify a higer price.  Sorta like that ALU whatsit thingy.  Go ahead ignore
all this stuff and go merrily on your way.  Just stay away from pacemakers
and nuclear power plant control systems.  (By the way, does Mommy know
you're playing with the 'puter again?)

> like if in the delay i poll some lines and call a function if the
> lines are in a certain state.
>
> The delay wont matter.  it is trivial.
>
> but if the stack overflows (ie the delay poll call a function which
> does the same delay routine and call another, and on till the stack
> overflows.) what happens?

It starts forgetting how to return from the outer subroutines.

> does it reset the stack? (empty it like)

No, it starts loosing things off the end, like.

> would it matter?

Does it matter if your subroutines return from where they were called, or is
it OK if they return to after a more recent call?



*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, .....olinKILLspamspam@spam@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2001\01\25@142320 by David VanHorn

flavicon
face
>
> > would it matter?
>
>Does it matter if your subroutines return from where they were called, or is
>it OK if they return to after a more recent call?

It's a feature :)
--
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2001\01\25@142535 by M. Adam Davis

flavicon
face
Andy N1YEW wrote:
> Is there a problem if my code overflows the stack?

It won't hurt the chip, but your program will essentially forget where to
go back to.  The stack is an area that hold information about jumps and
function calls.

Let's say you have a 2 level stack, which is empty now:

Call funcA     ; goto funcA, and come back here when it's done
Call funcB     ; goto funcB, return when done
Call funcC     ; goto funcC, return when done
...

funcA           ; At this point, the stack stores where it's supposed to return to
return         ; the stack 'pops' the value off, and the program continues
running right after
               ; the call func A instruction.  The stack only had to store one of these
values

funcB           ; Again the stack stores the location of the call funcB instruction
Call funcA     ; Now it's going to call A, and store this location
return         ; While A is running, the stack (2 level) is completely full.

funcC           ; Again, the stack stores the location of the Call funcC
instruction
Call funcB     ; Now it calls B, which stores another location
return         ; But B calls A!  This is called a stack overflow, the first
location that
               ; was stored (the original Call funcC) is now lost.  When it hits
               ; the return in funcC, it won't go where we thought it would,
               ; in fact, we have no idea wher it might go next, it could go to the
               ; end of our program, it could go back to the beginning, it could end up
               ; anywhere in between.

This is what is called a stack overflow.  You have too many calls with too
few returns, and the processor cannot keep track of where you meant to go
back to.

> like if in the delay i poll some lines and call a function if the lines are in a certain state.
> The delay wont matter.  it is trivial.
> but if the stack overflows (ie the delay poll call a function which does the same delay routine and call another, and on till the stack overflows.) what happens?

If you call the delay, the delay calls another function, then your stack
is full.  If that function now calls the delay (or any other function) you
will push the first value off the stack (overflow it) and your program
will not go back to the original call to delay.

> does it reset the stack? (empty it like)

The value of the stack if you use return more than twice without any calls
is undefined.  It may be clear (empty), or it may be random garbage.

> would it matter?

It only matters if you want to use calls and returns, or interrupts.  If
you never use call or return, and never use interrupts you'll never have
to worry about the stack.  But it makes things so much easier, so I would
use it when you can.

-Adam

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2001\01\25@152311 by Bob Ammerman

picon face
How the stack behaves on underflow/overflow depends on the particular flavor
of PIC.

See your datasheet.

Here are a couple examples:

for the 16F87x (which has an 8 slot stack) the datasheet says:

"The stack operates as a circular buffer. This means that
after the stack has been PUSHed eight times, the ninth
push overwrites the value that was stored from the first
push. The tenth push overwrites the second push (and
so on)."

On these chips a CALL or INTERRUPT will always push an address on the stack,
a RETURN/RETLW/RETFIE will always pop an address off the stack. In reality
no data moves on the stack, instead an invisible (to your program)  3-bit
pointer is incremented/decremented to point to a different stack slot.

for the 18Cxxx (which has a 31 slot stack) things are a little fancier. The
datasheet tells us:

The action that takes place when the stack becomes
full depends on the state of the STVREN (stack over-flow
reset enable) configuration bit. Refer to Section 18
for a description of the device configuration bits. If
STVREN is set (default) the 31st push will push the (PC
+ 2) value onto the stack, set the STKFUL bit, and reset
the device. The STKFUL bit will remain set and the
stack pointer will be set to 0.
If STVREN is cleared, the STKFUL bit will be set on the
31st push and the stack pointer will increment to 31.
The 32nd push will overwrite the 31st push (and so on),
while STKPTR remains at 31.
When the stack has been popped enough times to
unload the stack, the next pop will return a value of zero
to the PC and sets the STKUNF bit, while the stack
pointer remains at 0. The STKUNF bit will remain set
until cleared in software or a POR occurs.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2001\01\25@155827 by Andy N1YEW

picon face
Ok Thanks guys!

Exactly what I wanted to hear :)

Andy

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\01\25@160511 by Drew Vassallo

picon face
> > Is there a problem if my code overflows the stack?
>
>No, a stack is just one of those silly frills Microchip puts in there to
>justify a higer price.  Sorta like that ALU whatsit thingy.  Go ahead
>ignore
>all this stuff and go merrily on your way.  Just stay away from pacemakers
>and nuclear power plant control systems.  (By the way, does Mommy know
>you're playing with the 'puter again?)
.
.
.
> > would it matter?
>
>Does it matter if your subroutines return from where they were called, or
>is
>it OK if they return to after a more recent call?

Ouch.  Olin, I sense that you may be hinting at sarcasm here.  You having a
bad day?  Take it easy, there are lots of beginners out there... you were
one once, weren't you? :)

To answer the original question briefly:  the F84 has an 8-level hardware
stack which holds the program counters during program branching.  Once you
jump to a subroutine, or an interrupt, the current program counter (where
you are in the program before the jump) gets pushed onto the stack.  It
pushes all the other values down also.  If you jump to more than 8
consecutive locations, the stack will overflow and you will lose your first
location value.  Then, when you try to RETURN to that particular calling
location, it will return to the wrong place because the stack now contains
an incorrect program location.

There are no flag bits to tell you when you've overflowed the stack.  So
just don't.

--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2001\01\26@051243 by Vasile Surducan

flavicon
face
Olin
 He, he, is this an american joking style or just you've weak up
again with your left face on the pillow ?
Vasile


On Thu, 25 Jan 2001, Olin Lathrop wrote:

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu


2001\01\26@063248 by Roman Black

flavicon
face
Bob Ammerman wrote:
>
> How the stack behaves on underflow/overflow depends on the particular flavor
> of PIC.
>
> See your datasheet.
>
> Here are a couple examples:
>
> for the 16F87x (which has an 8 slot stack) the datasheet says:
>
> "The stack operates as a circular buffer. This means that
> after the stack has been PUSHed eight times, the ninth
> push overwrites the value that was stored from the first
> push. The tenth push overwrites the second push (and
> so on)."


Yep, I knew it was a circular stack, but when I read
your post a funny thought occured to me. Since the stack
is circular, you could call a function ANY amount of times,
and return the same amount of times, provided:
* It was originally called from the top level
* no ints or other functions were called.

This would give an option to do a recursive activity
a very large number of times??

Any opinions?? :o)
-Roman

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamTakeThisOuTmitvma.mit.edu


2001\01\26@090625 by Olin Lathrop

face picon face
> Since the stack
> is circular, you could call a function ANY amount of times,
> and return the same amount of times, provided:
> * It was originally called from the top level
> * no ints or other functions were called.
>
> This would give an option to do a recursive activity
> a very large number of times??

An infinite number of times, actually.  That is because the recursive
routine would only be able to return to itself and no longer be able to
return to the original caller.

If you think about it hard enough, you can probably contrive a case where
you can use the limited stack as a "feature", but I personally don't want to
go there.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olinEraseMEspam.....embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspammitvma.mit.edu


2001\01\26@092042 by Bob Ammerman

picon face
> Yep, I knew it was a circular stack, but when I read
> your post a funny thought occured to me. Since the stack
> is circular, you could call a function ANY amount of times,
> and return the same amount of times, provided:
> * It was originally called from the top level
> * no ints or other functions were called.
>
> This would give an option to do a recursive activity
> a very large number of times??
>
> Any opinions?? :o)
> -Roman
>

Sorry Roman, this won't work.

Remember the stack stores return addresses, not function addresses.

Given:

main:
   call     func
point_a:
   ...


func:
   ...
   call       func
point_b:
   ...
   return

After 8 calls every "return" will go back to "point_b", and we'll never get
back to "point_a".

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestEraseMEspamEraseMEmitvma.mit.edu


2001\01\26@093158 by Bob Ammerman

picon face
> Yep, I knew it was a circular stack, but when I read
> your post a funny thought occured to me. Since the stack
> is circular, you could call a function ANY amount of times,
> and return the same amount of times, provided:
> * It was originally called from the top level
> * no ints or other functions were called.
>
> This would give an option to do a recursive activity
> a very large number of times??
>
> Any opinions?? :o)
> -Roman

Sorry, Roman. Remember the stack stores _return_ addresses, not the address
of the called function.

So: given:

main:
   call    func
pointa:
   ...

func:
   ...
   call    func
pointb:
   ...
   return

After we recursively called func more than 8 times every subsequent 'return'
would return to 'pointb', not to 'pointa'.

i

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspam_OUTspamKILLspammitvma.mit.edu


2001\01\26@095224 by Roman Black

flavicon
face
Olin Lathrop wrote:
>
> > Since the stack
> > is circular, you could call a function ANY amount of times,
> > and return the same amount of times, provided:
> > * It was originally called from the top level
> > * no ints or other functions were called.
> >
> > This would give an option to do a recursive activity
> > a very large number of times??
>
> An infinite number of times, actually.  That is because the recursive
> routine would only be able to return to itself and no longer be able to
> return to the original caller.

Ha ha! Of course! After 8 calls the original address
will be rubbed... Whooops! I'll work on my projects HARDWARE
today I think. It's a good day for hardware! ;o)
-Roman

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspamspammitvma.mit.edu


2001\01\26@095643 by Lawrence Lile

flavicon
face
Bob,

I just read about a RAM company in IL who developed some small parts choking
models for the CDC, some CAD software models as well as a physical model of
a child complete with  breathing functions and a scale model throat.  It's
more useful than the abbreviated plastic tube used in the industry today.
They also developed a cruncher with the same forces as a baby's teeth (to
see if a toy would fly abart when bitten) and a pull tester with the same
grip force and strength as a small child to see if a toy would pull apart
under forces a child could generate.  That wasn't you, was it?

-- Lawrence Lile

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspamspamspamBeGonemitvma.mit.edu


2001\01\26@104334 by Drew Vassallo

picon face
>main:
>     call    func
>pointa:
>     ...
>
>func:
>     ...
>     call    func
>pointb:
>     ...
>     return

Wouldn't this just keep cycling between "func:" and "call func", never
getting to the "return" instruction?
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2001\01\26@115958 by Dan Michaels

flavicon
face
Roman wrote:
........
>
>Yep, I knew it was a circular stack, but when I read
>your post a funny thought occured to me. Since the stack
>is circular, you could call a function ANY amount of times,
>and return the same amount of times, provided:
>* It was originally called from the top level
>* no ints or other functions were called.
>
>This would give an option to do a recursive activity
>a very large number of times??
>
>Any opinions?? :o)


Forget it. Recursive routines generally use the stack
to store "local" variables, and if too many levels are in
use, you can easily overflow it with your data, besides
return addresses -[on older 80x86, at least]. And If you
only use global variables, then you would be continually
overwriting them - also called non-re-enterable routines,
the bane of M$-DOS and other non-multitasking OSes.

Existence of the circular stack on some PICs, however
means you can use a s.w. bailout to go to the beginning of
your program from "anywhere" in your code - no matter what
is already on the stack. I use this method to bailout of
some routines that are so tightly coded that there isn't
space to add a < btfs_ + goto >. [this is probably the
place Olin just said he didn't want to go to].

- danM

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestSTOPspamspamspam_OUTmitvma.mit.edu


2001\01\26@120823 by jamesnewton

face picon face
The problem would be stopping when you make it back to the top.

---
James Newton (PICList Admin #3)
spamBeGonejamesnewtonSTOPspamspamEraseMEpiclist.com 1-619-652-0593
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}

2001\01\26@174554 by Bob Ammerman

picon face
> >main:
> >     call    func
> >pointa:
> >     ...
> >
> >func:
> >     ...
> >     call    func
> >pointb:
> >     ...
> >     return
>
> Wouldn't this just keep cycling between "func:" and "call func", never
> getting to the "return" instruction?

Yes, except that the "..."s represent additional code that would determine
when to exit the recursion.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...