Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Changing stack sizes in Win32Forth

77 views
Skip to first unread message

Elko Tchernev

unread,
May 18, 1997, 3:00:00 AM5/18/97
to

Hi, all,
has somebody tried to increase the return and data stack sizes
of W32F? The only place I see any reference to their size is in FKERNEL.F:
\ -------------------- Cold Start Entry Point --------------------

LABEL _COLD1
pop edi
sub edi, 0 [edi] \ edi = forth base
etc..
but there it is used as an immediate constant:
sub esp, # 8000 \ room for return stack

I tried to increase it, but it only goes up to 10000 without causing access
violations. I can't believe this is the place where those sizes are set;
but if it is in the C compiler, it's not obvious from the makefile.
Anyway, I need both stacks 64K each, or at least 32K.
Cheers!
-----------------------------------------------------------------------
Elko Tchernev I want to be a nothing-knower,
tche...@hermes.msci.memphis.edu a little ant on any hill;
tche...@memphis.edu for time is dead, the sun is over
tel/fax (901) 678 7304 and there is nothing left to kill.


Tom Zimmer

unread,
May 18, 1997, 3:00:00 AM5/18/97
to

In article <5lm6ca$n...@oolong.memphis.edu>,
tche...@hermes.msci.memphis.edu wrote:

> Hi, all,
> has somebody tried to increase the return and data stack sizes
> of W32F? The only place I see any reference to their size is in FKERNEL.F:
> \ -------------------- Cold Start Entry Point --------------------
>
> LABEL _COLD1
> pop edi
> sub edi, 0 [edi] \ edi = forth base
> etc..
> but there it is used as an immediate constant:
> sub esp, # 8000 \ room for return stack
>
> I tried to increase it, but it only goes up to 10000 without causing access
> violations. I can't believe this is the place where those sizes are set;
> but if it is in the C compiler, it's not obvious from the makefile.
> Anyway, I need both stacks 64K each, or at least 32K.

The data stack is a megabyte, which is standard in Windows95 and
Windows NT. You are right about the return stack, you should just
change it to be larger, then be sure to probe the stack at about 4k
intervals, to make sure that Windows allocates the space properly.

It will cause an access violation if you just store into the data
stack (which is where the return stack is allocated out of) more
than about 4k from the current stack pointer, or the last access,
which ever is lesser. That is what those extra instructions storing
into the stack in 4k steps are for, to force allocation of the space
and prevent windows from invoking an exception.

Strange but true!

--
Tom Zimmer

Andrew McKewan

unread,
May 20, 1997, 3:00:00 AM5/20/97
to

The reason for the stack probing is that Windows reserves 1 MB for a
stack, but does not commit (allocate) the memory. Instead it allocates a
few pages and then marks the next page as a guard page. When you
reference that page, it is allocated and the page below that is marked
as the guard page. If you skip the guard page and try to access one of
the reserved pages, you get an access violation.

+------------+ <--- bottom of stack (high memory address)
| committed |
| pages | <--- stack pointer
+------------+
| guard page |
+------------+
| reserved |
| pages |
| |
+------------+

In Win32Forth the return stack is allocated from the data (processor)
stack. So you should increase the stack with a loop of the following
code: (this will allocate 80,000 bytes)

mov ecx, # 20 ; number of pages to allocate
@@1: sub esp, # 4000 ; allocate < one page (4096 in Intel platforms)
mov [esp], eax ; "touch" memory
loop @@1

----------------------------------------------------------------------
Andrew McKewan mck...@austin.finnigan.com
Finnigan Corporation
2215 Grand Avenue Parkway Tel: (512) 251-1574
Austin, TX 78728-3812 Fax: (512) 251-1547

0 new messages