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

Groups > comp.lang.forth > #45043

Re: Stack space size

Show all headers | View raw

Rod Pemberton wrote:
> On Thu, 21 Jan 2016 21:50:40 -0800 (PST)
> Brad Eckert <hwfwguy@gmail.com> wrote:
>
> > What's the typical stack space you find you need in embedded
> > application
>
> ...
>
> > and what things cause that to grow.
>
> From this group, my understanding is that user defined words
> shouldn't leave items on the data or return stacks.  This means
> a net stack change of zero for both stacks.  So, that would
> mean that system words are the primary source of stack bloat
> or growth.  Most usage of stack "producers" is immediately
> followed by stack "consumers".  You're probably interested in
> functionality which is "split" or wraps around other words,
> e.g., >R ... R> or DO ... LOOP or BEGIN ... AGAIN, etc.
> I.e., look for control flow and "do" and "undo" operations.
> The stack image for the words in your dictionary could be
> a useful starting point.  Which words leave stuff on the
> stacks?
>
> > As for me, 64 cells
> > per task (32 cells each for data and return) is fine. I just fill
> > them with $55 at init and dump at run time to see how tight things
> > are.
>
> When you run the standard Forth test programs, like sieve, bubble,
> matrix, fib, quick sort, 8-queens, life, hanoi, etc, how much stack
> pressure do you see?  Test apps should provide a good baseline
> reference as to whether you're about to overflow the stack.
>
> > Metrics in Phil Koopman's Stack Machines book indicate that 32-cell
> > data and return stacks handle whatever you throw at them, in general.
>
> Section 6.4.1.  See also 6.5.3.1., which indicates slightly larger.
>
> Anton Ertl has a paper titled "Ways to Reduce the Stack Depth"
> which reviews various techniques.  The paper basically concludes
> that locals are the best solution, but that other combinations
> of other solutions work as well.  I've only skimmed one section
> and the summary, so you'll need to read it yourself.
>
>
> Rod Pemberton

Locals chew up return stack and unlike data stack the space won't
be released until the definition ends.  Nest several definitions each
containing locals and work out the return stack requirements.  Add
to this the data stack that locals will use anyway.  Locals provide
convenience - not memory efficiency.

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Stack space size Brad Eckert <hwfwguy@gmail.com> - 2016-01-21 21:50 -0800
  Re: Stack space size hughaguilar96@gmail.com - 2016-01-21 22:00 -0800
  Re: Stack space size Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-21 22:30 -0800
    Small strings as ints Ron Aaron <rambamist@gmail.com> - 2016-01-22 08:41 +0200
      Re: Small strings as ints Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-21 23:41 -0800
        Re: Small strings as ints Ron Aaron <rambamist@gmail.com> - 2016-01-22 09:50 +0200
      Re: Small strings as ints Ron Aaron <rambamist@gmail.com> - 2016-01-24 07:15 +0200
  Re: Stack space size anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-22 15:31 +0000
  Re: Stack space size Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-22 17:10 -0500
    Re: Stack space size Coos Haak <chforth@hccnet.nl> - 2016-01-22 23:21 +0100
      Re: Stack space size "Elizabeth D. Rather" <erather@forth.com> - 2016-01-22 13:28 -1000
        Re: Stack space size hughaguilar96@gmail.com - 2016-01-25 21:23 -0800
    Re: Stack space size "HAA" <someone@microsoft.com> - 2016-01-24 00:08 +1100
    Re: Stack space size anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-26 16:23 +0000

csiph-web