At 15:48 -0800 2000/03/04, Andy Gill wrote:
>Hugs uses the C stack during evaluation.
I gather this is the parameter stack provided by the C compiler. Right?
It is this stack that
>can fill up, and cause the program to fail, in the same way that
>a C program might fail on deep recursion. Changing the size of
>the stack in very OS specific. On Windows you can set a field
>in the .exe file that tells the OS how big the stack should be,
>for example.
...
>If you want more stack size, then you need
>to get out an OS manual and C compiler documentation, and figure
>out the specifics for your combination.
I implemented such a thing on the Mac port, and it was not so difficult.
The MacOS does not really provide a stack, but is an area at the top of the
program memory allocation, growing downwards. Setting a stack size does not
affect the size of the stack at all, but prevents the free store memory
allocation to grow into it. Therefore, if the stack is allowed to grow
without proper stack overflow checks, it will expand into the free store
area, and the program will bomb. The Mac port has such stack checks, taken
from the Gofer written by Kevin Hammond.
If WOS (Windows OS) works in a similar fashion, one might check for an OS
command that sets the sizes of these partitions.
If the WOS port does not do any stack overflow checks, a dirty solution
might be to simply allocate more memory for Hugs: Hugs does not use much
free store while running as it has its own GC, so if you are lucky, the
stack growing into the free store area will not bomb Hugs.
>The great news is that STG Hugs shares evaluation technology with
>GHC. It does not use the C stack, so we can allocate more stack
>on the fly if needed.
How do you avoid using the C stack if the compiler is written in C?
I mean, one must use some C function calls to start the program, and then
the C stack is used. Or is the stack only expanded when there are some
local function variables, so if one merely is avoiding those, the stack
does not expand?
Hans Aberg
