whoffman@topaz.UUCP (04/02/87)
hello,
This is a question for all you turbo pascal users out there. any
help (if i can be helped) would be appreciated. while running a turbo
program that makes extensive recursive calls i stumble upon a runtime
error "ff" which evidentily means i have a stack heap collision
according to the manual. is there any way to overcome this problem
without removing the recursion? (it isnt neccessarily a recursive call
that fails, sometimes its just a call to another procedure from within
a recursive call) . Thanks again for the info...
bill.
William R. Hoffman
Arpa: whoffman@topaz.rutgers.edu or whoffman@red.rutgers.edu
Uucp: ...{harvard | seismo | pyramid}!rutgers!topaz!whoffmanmadd@bucsb.bu.edu.UUCP (04/02/87)
In article <10629@topaz.RUTGERS.EDU> whoffman@topaz.UUCP writes: >while running a turbo >program that makes extensive recursive calls i stumble upon a runtime >error "ff" which evidentily means i have a stack heap collision >according to the manual. is there any way to overcome this problem >without removing the recursion? (it isnt neccessarily a recursive call >that fails, sometimes its just a call to another procedure from within >a recursive call) . If you are having problems with depth of recursion, there are several things you can do to fix them. The easiest (well, not really) is to get a bigger machine. Obviously this isn't what you're looking for, but it's still a solution :-). Aside from this, you have to make each call to a procedure smaller. To do this, try to eliminate unnecessary variable passing. If you're passing the same variable many times without changing it, put it in a global and don't pass it. Also, if you are passing large objects (such as strings), you should look into the possibility of passing them as "var" types, as follows: type str = string[255]; procedure foo(s : str); This way of passing a string will take 256 bytes of stack space, while: procedure foo2(var s : str); will take only 4 or so (aside from the normal overhead, that is). This is because var declarations in TPascal cause the passing of a pointer and not the actual object (I think -- you should look it up, but I'd bet money on it, since it's standard practice in compilers). Note that cutting out extra parameters and changing parameters to "var" types will also increase performance, since there is less duplication of data. This is usually minimal, but can show up in a few thousand calls. Aside from these, the only other way to approach the heap/stack collision problem is to try to make your program nonrecursive. If it's possible to do this without using stacks, then do it. Otherwise, you'll have more problems with stack management and such, so you should just try to work with cutting down the recursion's requirements. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Jim Frost * The Madd Hacker | UUCP: ..!harvard!bu-cs!bucsb!madd H H | ARPA: madd@bucsb.bu.edu H-C-C-OH <- heehee +---------+---------------------------------- H H | "We are strangers in a world we never made"
rod@cpocd2.UUCP (04/03/87)
In article <10629@topaz.RUTGERS.EDU> whoffman@topaz.UUCP writes: > >hello, > > This is a question for all you turbo pascal users out there. any >help (if i can be helped) would be appreciated. while running a turbo >program that makes extensive recursive calls i stumble upon a runtime >error "ff" which evidentily means i have a stack heap collision >according to the manual. is there any way to overcome this problem >without removing the recursion? (it isnt neccessarily a recursive call >that fails, sometimes its just a call to another procedure from within >a recursive call) . Thanks again for the info... > The "heap" is where memory is allocated for such things as pointers, records, etc. This gets eaten up with calls to allocate new records using the "new" procedure. The "stack" is where Turbo allocates memory for temporarily storing (pushing) the variables used within your recursive procedure prior to calling itself, so that they can be restored upon re-entering (poping) the procedure from that call. These two areas are at opposite ends of memory and 'grow' towards each other as space is allocated. The collision occurs when they meet. The only way I know of to prevent this is to limit the number of recursive calls, or if possible, reduce the amount of heap required by reducing NEW calls. Also try to reduce the number and size of variables that have to be saved before each recursive call. -- Rod Rebello ...!intelca!mipos3!cpocd2!rod