dkp@hadron.UUCP (David K. Purks) (08/31/87)
I finally got the source to nethack upgraded from the patches that were sent through comp.sources.games and ran it for the first time. All it keeps wanting to do is tell me ERROR 2000: OUT OF STACK SPACE. I've relinked the program with STACK:9000 and still have the same problem. Has anyone gotten it to work or know what I might have done wrong? Dave Purks seismo!hadron!dkp
iverson@cory.Berkeley.EDU (Tim Iverson) (09/01/87)
In article <616@hadron.UUCP> dkp@hadron.UUCP (David K. Purks) writes: > I finally got the source to nethack upgraded from the patches > that were sent through comp.sources.games and ran it for the > first time. All it keeps wanting to do is tell me ERROR 2000: > OUT OF STACK SPACE. I've relinked the program with STACK:9000 > and still have the same problem. Has anyone gotten it to work > or know what I might have done wrong? Yes, I had the same problem. I tried stacks up to 64k, but I always got the same lack of stack space. Then I tried smaller stacks - and guess what? It worked! The limit is somewhere between 0a00 and 0b00 (a00 works fine, but b00 doesn't). If someone out there understands exactly why it works with a small stack but not a large one, I'd really like to know. To forstall bad guesses, its not that I don't have enough memory - I checked that and the message when there's not enough memory is simply 'not enough memory'. Since this is large model, the stack and heap are separate, so it can't be that they're colliding on the early allocations. I have another large program (.exe > 300k, large model) that uses lots of stack space (32k) without any problems whatsoever, though my code is much cleaner and portable (for an example of truly stupid code, take a look at makemon() in makemon.c), so I don't think the fault is totaly with the compiler. - Tim Iverson iverson@cory.Berkeley.EDU ucbvax!cory!iverson
dhesi@bsu-cs.UUCP (09/02/87)
In article <3470@zen.berkeley.edu> iverson@cory.Berkeley.EDU.UUCP (Tim Iverson) writes (about setting a stack for hack.exe under MSDOS): >I tried stacks up to 64k, but I always >got the same lack of stack space. Then I tried smaller stacks - and guess >what? It worked! The limit is somewhere between 0a00 and 0b00 (a00 works >fine, but b00 doesn't). If someone out there understands exactly why it >works with a small stack but not a large one, I'd really like to know. A lot of things under MS-DOS are measured in units of 16-byte clicks. Thus, when you specify a stack of 0xa00 bytes, you may be really specifying 0xa00 clicks, which is 0xa000 bytes or 40 kilobytes. Since the stack segment can't exceed 64 kilobytes, specifying too large a stack will cause overflow. Unfortunately, the Microsoft linker doesn't seem to give a warning when this happens, and just seems to use some unknown value instead. Also note that, depending upon the memory model and the options you specify to the compiler, the stack may share a segment with static (non-stack) data, limiting the stack itself to less than a full segment. -- Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi
iverson@cory.Berkeley.EDU.UUCP (09/03/87)
In article <1079@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <3470@zen.berkeley.edu> iverson@cory.Berkeley.EDU.UUCP (Tim >Iverson) writes (about setting a stack for hack.exe under MSDOS): > >>I tried stacks up to 64k, but I always >>got the same lack of stack space. Then I tried smaller stacks - and guess >>what? It worked! The limit is somewhere between 0a00 and 0b00 (a00 works >>fine, but b00 doesn't). If someone out there understands exactly why it >>works with a small stack but not a large one, I'd really like to know. > >A lot of things under MS-DOS are measured in units of 16-byte clicks. Stacks aren't - both using the linker and using exemod, they're measured in bytes. Min/Max *paragraphs* (as in exemod) is measured in 16-byte units. >Also note that, depending upon the memory model and the options you >specify to the compiler, the stack may share a segment with static >(non-stack) data, limiting the stack itself to less than a full >segment. Yes! I just looked at the manual under segements (previously I had looked at the 'stack' and 'heap' entries, but was not enlightened) and it states that in *all* models the stack segment is shared with initialized static and global data. It also presents ways to change this using custom memory models, but then states that if you use a custom model, you'll have to use your own library. Instead, I set -Gt 10, which would then put all the init'd data >10 bytes into unique segements without negating the usefullness of the library. This works quite well - thanks Rahul! - Tim Iverson iverson@cory.Berkeley.EDU ucbvax!cory!iverson
qwerty@drutx.ATT.COM (Brian Jones) (09/03/87)
In article <1079@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
) In article <3470@zen.berkeley.edu> iverson@cory.Berkeley.EDU.UUCP (Tim
) Iverson) writes (about setting a stack for hack.exe under MSDOS):
)
) >I tried stacks up to 64k, but I always ...
)
) A lot of things under MS-DOS are measured in units of 16-byte clicks.
) Thus, when you specify a stack of 0xa00 bytes, you may be really
) specifying 0xa00 clicks, which is 0xa000 bytes or 40 kilobytes. Since
) the stack segment can't exceed 64 kilobytes, specifying too large a
) stack will cause overflow. Unfortunately, the Microsoft linker doesn't
) seem to give a warning when this happens, and just seems to use some
) unknown value instead.
The above 'information' is INCORRECT.
Both the MASM and MSC manuals specify the /STACK:number option as specifying
the number of BYTES to be allocated to the stack.
Also, the 16-byte 'clicks' are normally referred to as PARAGRAPHS.
)
) Also note that, depending upon the memory model and the options you
) specify to the compiler, the stack may share a segment with static
) (non-stack) data, limiting the stack itself to less than a full
) segment.
) --
This is probably what's going on.
) Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi
Note: markings on included text changed to circumvent the silly software
checks.
--
Brian Jones aka {ihnp4,allegra}!{drutx}!qwerty @ AT&T-IS, Denverdhesi@bsu-cs.UUCP (Rahul Dhesi) (09/04/87)
I wrote:
A lot of things under MS-DOS are measured in units of 16-byte
clicks. Thus, when you specify a stack of 0xa00 bytes, you may be
really specifying 0xa00 clicks, which is 0xa000 bytes or 40
kilobytes.
Brian Jones triumphantly declares:
The above 'information' is INCORRECT.
Both the MASM and MSC manuals specify the /STACK:number option as
specifying the number of BYTES to be allocated to the stack. >
This is technically correct for the version of the linker I have, but
misses the basic point.
The basic point is that Microsoft uses units and notation very
inconsistently. Sometimes Microsoft uses bytes, sometimes 16-byte
clicks. Sometimes Microsoft uses decimal, sometimes hexadecimal, and
sometimes you get a choice.
For the linker, you either have to use bytes, or 16-byte clicks,
depending on the particular option you are specifying. My version of
the linker, which is about two years old, wants /STACK in bytes but
/CPARMAXALLOC in 16-byte clicks. This is no guarantee that other
versions of the linker want the same units.
There are plenty of examples of confusion. One that sticks in my mind
is that in earlier versions of MS-DOS, you needed to specify
environment space to the command interpreter in 16-byte units. Then
suddenly, a version later, you had to specify it in bytes.
The moral is to make sure you always double-check the units and the
notation needed.
--
Rahul Dhesi UUCP: {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesigreg@smash.CTS.COM (Greg Laskin) (09/06/87)
In article <1079@bsu-cs.UUCP< dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
<In article <3470@zen.berkeley.edu< iverson@cory.Berkeley.EDU.UUCP (Tim
<Iverson) writes (about setting a stack for hack.exe under MSDOS):
<
<<I tried stacks up to 64k, but I always
<<got the same lack of stack space. Then I tried smaller stacks - and guess
<<what? It worked! The limit is somewhere between 0a00 and 0b00 (a00 works
<<fine, but b00 doesn't). If someone out there understands exactly why it
<<works with a small stack but not a large one, I'd really like to know.
<
<A lot of things under MS-DOS are measured in units of 16-byte clicks.
<Thus, when you specify a stack of 0xa00 bytes, you may be really
<specifying 0xa00 clicks, which is 0xa000 bytes or 40 kilobytes. Since
<the stack segment can't exceed 64 kilobytes, specifying too large a
<stack will cause overflow. Unfortunately, the Microsoft linker doesn't
<seem to give a warning when this happens, and just seems to use some
<unknown value instead.
<
This is incorrect. The -F switch specification gives stack size in BYTES
not PARAGRAPHS. -F 0A00 gives a stack of 2.5K. The default is 2K.
<Also note that, depending upon the memory model and the options you
<specify to the compiler, the stack may share a segment with static
<(non-stack) data, limiting the stack itself to less than a full
<segment.
There is an upper bound to the size of the stack. That is the space left
in the _DATA segment after everything else gets stuffed in it. The _DATA
segment gets all the static initialized variable including "string"
constants. If you look at a map (link with -m hack.map) you'll see
that there's very little space left for the stack in _DATA. _DATA
is limited to 64K total.
You can use -Gt# to place initialized variables ># in size in a separate
module, thus removing them from _DATA and leaving more room for the
stack.
--
Greg Laskin
"When everybody's talking and nobody's listening, how can we decide?"
INTERNET: laskin@gryphon.CTS.COM
UUCP: {hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!laskin