Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!xanth!mcnc!rti!sas!walker
From: walker@sas.UUCP (Doug Walker)
Newsgroups: comp.sys.amiga
Subject: Re: Is she c:Stack'd
Message-ID: <1278@sas.UUCP>
Date: 13 Oct 89 14:23:17 GMT
References: <3944@m2-net.UUCP> <125522@sun.Eng.Sun.COM>
Reply-To: walker@sas.UUCP (Doug Walker)
Organization: SAS Institute Inc, Cary NC
Lines: 66

In article <125522@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes:
>In article <3944@m2-net.UUCP> ba@m-net.UUCP (Bill Allen) writes:
>Depends on what they put there. Some programs, like anything compiled
>with Lattice 5.x will adjust the stack when they start up, others just
>take what you give them.  
Not quite true, Chuck.  If you link with cres.o or cback.o it adjusts
your stack for you;  if you link with the normal c.o it doesn't.  However,
Lattice does CHECK your stack size for you unless you specify -v;  if your
program overruns the stack, a requester will pop up.

>
>> Can other programming techniques be used to prevent this?  
>
Sure.  Allocate everything with AllocMem, or declare variables static or
extern.  The following items get put on the stack:

1) Local variables (autos)
2) Function parameters
3) Function return values
4) Register saves
5) Temporary values that spill out of registers (generally a VERY small 
   number, less than 20 bytes).

The deeper your nesting level, the more stack you will need.  Thus,
recursive programs can be a problem.  I once had an application using 
N-way trees (each node can have 1-n children) and I walked the tree
using


   callmyself(rightsibling);
   callmyself(leftmostson);
   processmyself();

I thought this worked great!  Very little code, really efficient, right?
WRONG!  The trees I was dealing with were perhaps 4-5 levels deep, but
very broad.  The callmyself(rightsibling) was pushing itself onto the
stack once for each sibling at a given level.  I very quickly discovered
that stack size IS a problem!  I changed the code to

   for(current=me; current != NULL; current=current->rightsibling)
      callmyself(current->leftmostson);
   processmyself();

This relatively small code change saved THOUSANDS OF BYTES of stack,
while doing exactly the same thing as the previous code.


>> Is this "poor" programming or are there legitimate needs for 
>> unavoidable minimum 60,000+ byte stack.
>
>There are legitimate reasons why you might need lots of stack space
>but I can't think of any off the top of my head :-). 

The only reason would be very deep, legitimate recursion.  (By 'legitimate'
I mean 'unavoidable by simple tricks like above').  Cases that require
this kind of recursion are extremely rare.  99% of the time the 60K stack
requirement is due to the programmer allocating large auto arrays.
Remember, folks, any arrays you allocate in main() remain on the stack
the whole time you are running;  if you can do your parsing in a subroutine
instead of main(), for example, all the auto variables you used during parsing
will go away when you return.

>
>--Chuck McManis

--Doug Walker