Stack depths?

forth

    Sponsored Links

    Next

  • 1. need an unoptimized Forth :)
    For educational purposes, I need a Forth for i386 coded straightforwardly, preferrably for Linux. That is, see dup must show code dup pop eax push eax push eax next, end-code and see @ should show something like code @ pop eax push [eax] next, end-code Ability to use variable names as operands is a plus, e.g. variable MYVAR code xyz mov eax, [] MYVAR push eax ... The closest match is F-PC, but it's 16-bit. (Forth is the best user-friendly interface for Assembler)
  • 2. Forth200x structures frustration
    I have an issue with the Forth200x structures; setting a negative field offset is difficult & inefficient. Some of the structures I wish to define start at negative offsets. Example; begin-structure voc. field: voc.thrd field: voc.head field: voc.srch field: voc.iter field: voc.xt field: voc.link field: voc.#0 end-structure The link for this is at a 5 cell offset (voc.link) and voc.thrd is at offet -20. This adjustment begin-structure voc. -5 cells ... generates voc. with a length -5 cells too small. Other techniques to adjust require just too much code (such as subtracting a constant from every reference). I'd like to propose the addition of the word OFFSET. begin-structure voc. -5 cells offset field: ... end-structure

Stack depths?

Postby jacko » Tue, 12 Apr 2011 12:24:36 GMT

What is a reasonable one? Considering the nesting on a system, what's the order of complexity with say 512 cells for R and S. Enough for simple GUI apps?

Cheers Jacko

Re: Stack depths?

Postby BruceMcF » Tue, 12 Apr 2011 12:52:40 GMT



While my copy of gforth reports 4096 and 3840, my copy of SwiftForth
reports 1024 and 4096, and my copy of BigForth reports over 16,000
each, my copy of Win32Forth reports 256 and 256, so 512 each is by no
means the smallest of the fuller featured Forths I have on hand.

Is there a reason that graphical user interface apps would necessarily
be very deep?

Re: Stack depths?

Postby jacko » Tue, 12 Apr 2011 13:27:27 GMT

Maybe abstraction levels of the drawn objects. But maybe not.

Re: Stack depths?

Postby The Beez' » Tue, 12 Apr 2011 15:42:33 GMT


4tH features a shared data- and return stack of 512 cells, which is
still pretty deep IMHO. If you need that deep a stack, well, you got
either a pretty complex or stack intensive (recursion) application on
your hand. Note stack frames (CATCH-THROW) and local variables may add
to the burden.

 Usually, you can get away with a pretty shallow one:

ANS-Forth 12.3.3:
"The size of a floating-point stack shall be at least 6 items. A
program that depends on the floating-point stack being larger than six
items has an environmental dependency."

A program which requires a very deep stack is the Ackermann function:

: ackermann                            ( m n -- u )
  over 0=                              \ allow tail recursion
  IF
    nip 1+
  ELSE                                 ( m-1 n -- )
    swap 1- swap dup 0=
    IF
      1+ recurse
    ELSE
      1- over 1+ swap recurse recurse
    THEN
  THEN
;

Hans Bezemer


Re: Stack depths?

Postby Alex McDonald » Tue, 12 Apr 2011 17:15:53 GMT





Win32Forth (and it does depend on the version) uses a lot of stack for
certain kinds of Windows calls. Both the rstack and stack are
allocated from the provided application stack (default=1M). About the
bare minimum is 32K; less and calls walk all over the Forth stack,
particularly during Windows callbacks. This is due to the mechanism
used to allocate several stack frames from the single provided stack.

How did you ascertain the Win32Forth stack depths?

Re: Stack depths?

Postby Elizabeth D Rather » Wed, 13 Apr 2011 05:07:11 GMT



It really depends on what you're doing.  We have run profiles on some 
fairly complex applications and found neither stack had more than 8-10 
items on it at any one time.  But if you're doing something like a 
recursive area fill, that could require thousands.  Likewise, if you're 
using the Forth stacks for OS or C library calls you'll need a lot more 
than in a native or embedded implementation.  Windows calls use up vast 
amounts of stack.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
 http://www.**--****.com/ 

"Forth-based products and Services for real-time
applications since 1973."
==================================================

Re: Stack depths?

Postby jacko » Wed, 13 Apr 2011 06:08:53 GMT

I am fixing the stack pointer to certain memory areas, similar to page one on the 6502, and I am decided 512 cells each is suitable for 16 bit custom system OEM is ok.

Re: Stack depths?

Postby BruceMcF » Wed, 13 Apr 2011 07:23:00 GMT



I don't know what the Win32Forth stack depths are, that's just what
Win32Forth reports to environment? queries.

Re: Stack depths?

Postby MarkWills » Wed, 13 Apr 2011 08:13:05 GMT



Well, at boot-up, my hobby system has 20 cells for the data stack, and
30 for the return stack. You can move the stacks to other areas of
memory if you need more space, but I've never got anywhere close to
the limit in 'conventional' programming tasks. Probably the most I had
on the stack is 5 items.

Mark

Re: Stack depths?

Postby ron » Wed, 13 Apr 2011 13:33:34 GMT



"Reasonable" depends on what sort of usage you expect.

In Reva, the data stack is 2K, e.g. 2048 cells deep.  But each
callback gets its own stack, also 2K deep, allocated from the hardware
stack when the callback is invoked.  This is more than ample in my
experience, for both Windows and Linux GUI work.

Re: Stack depths?

Postby Alex McDonald » Wed, 13 Apr 2011 18:24:27 GMT





Ah, I see. Thanks.

Re: Stack depths?

Postby Albert van der Horst » Wed, 13 Apr 2011 19:12:03 GMT

In article < XXXX@XXXXX.COM >,





If you know you have a huge stack space, you can do things like
the following.

I want WORDS print the most recent words last, so I put them
on the stack first, then print them.

If the stack is addressable, you can allocate a temporary
largish buffer there.

etc.

So a large stack opens opportunities with environmental
dependancies.


Groetjes Albert


Re: Stack depths?

Postby Brad » Wed, 13 Apr 2011 23:53:42 GMT



Phil Koopman ( http://www.**--****.com/ ~koopman/stack_computers/
index.html) did a lot of investigation of stack sizes. 16-cell stacks
were sufficient 99% of the time and 32-cell stacks always worked. As
Elizabeth said, if you call Windows functions all bets are off.

If you're running on bare metal and building the code base from the
ground up, a 16-cell limit will most likely be no problem.

It sounds a little like you're looking at implementing a stack
machine. If so, look up James Bowman's J1. A nice little CPU expressed
in 200 lines of Verilog.

-Brad

Re: Stack depths?

Postby Alex McDonald » Thu, 14 Apr 2011 00:40:43 GMT





In spades. During Windows calls, a 64K stack is about the bare
minimum, although certain activities can blow even that away. The high
watermark I've seen for Windows calls on Win32Forth is just under
128K, measured by flooding the stack with hex rubbish like C7C7C7C7
and looking for the wreckage after the call. The call depth isn't
normally that great, but some functions appear to use quite a lot of
stack (many pages worth in some cases) for local storage. One nice
feature is that the stack can be adjusted by simply modifying the
executable header.



Re: Stack depths?

Postby jacko » Thu, 14 Apr 2011 05:35:54 GMT

 http://www.**--****.com/  X7 memory bandwidth is a real concern of design. Hence a singular unified external memory. But the instruction set and memory map are now considered release stable. (0.2 MIPS/MB)

CPLD size compliant. (Small core)

Cheers Jacko

P.S. split stack harvard maybe in the future but it's more likely to go dividing memory into an interleave of N parts, with the core data (registers and feed through cache) moving to the needed memory controller. Forward program motion one +1 at a time.

Similar Threads:

1.Syntax and stack depth

Anton Ertl wrote:
> Now, there are many possible ways to serialize general trees (e.g., 
> XML), but prefix is a good one: it works the same with all arities
> (in contrast to infix, which works only for arity 2), [...]

Although I'm not disagreeing with the larger substance of what you 
wrote, I don't think this last point is correct.

The ternary operator in C is, I think, an example of an infix operator 
that has arity 3.  Lexically the operator is spread over two characters 
(? and :), but logically, it's all part of a single operator.  One can 
further imagine other kinds of infix operators with arbitrary arity:

x = f $ a,b,c,d;

In this invented infix syntax, the operator "$" applies the function 
argument f in turn on each of the comma-separated arguments that 
follow-- and, well, does something presumably useful with them.  The 
point here is that infix operators can have arbitrary arity.

2.Stack depth

Hi,

I have 1 GB RAM and i use Fedora Core.
How many calls can be called recursively so that my stack does not get
corrupted ?
Any ideas ?

Thx in advans,
Karthik Balaguru

3.Stack depths?

What is a reasonable one? Considering the nesting on a system, what's the order of complexity with say 512 cells for R and S. Enough for simple GUI apps?

Cheers Jacko

4.How to trace stack depth

5.THROW and stack depth

According to DPANS94, when xcpt# <> 0, xcpt# THROW is required
to restore all stack depths to the values saved in the excpetion
frame by CATCH.  A.9.6.1.2275 warns that data stack entries may
have been changed by the part of the word executed by CATCH
before the THROW, and should not be relied upon.  The same
warning obviously applies to all other stacks in play, except
the return stack.

Could someone explain the utility of that?

Wouldn't it make sense instead to leave the data stack as it was
just before THROW?  In cases where one knows where the THROW
occurred, one could use the stack at that point for an
appropriate procedure.  If one doesn't know, then the meaning of
the restored depth seems problematic anyway.

It seems that often one would or could know, especially in the
case of application-defined exception numbers, even if the
procedure chooses to THROW the exception again.  If an
application CATCHes a system exception, it still seems that its
source could often be known, unless the exception is unexpected.
If it's unexpected, it's a bug that needs to get fixed.

I've only just started to use CATCH, and could well be off base
here.

-- David

6. Syntax and stack depth (was: [OT] PostLisp, a language experiment)

7. proof-of-concept stack depth checker

8. standard way to determine depth in stack



Return to forth

 

Who is online

Users browsing this forum: No registered users and 15 guest