[comp.unix.xenix] Not enough core

rem@remsit.UUCP (Roger Murray) (09/13/88)

I've been working on a program for the last couple of weeks and have run into
a snag.  The last couple of days, I've been adding a few functions to the
program.  They've all been relatively simple; all but one are smaller than
a screen in length.  This afternoon I planned on adding two more (in fact, the
last two).  I added the first one and put in added a few statements so I could
check to see that it worked.  I then put in the second function (which calls
the first) and everything compiled away just fine but when I went to run it,
I got "Not enough core".  The second function is all of three statements, so I
don't see how it could have done much, unless I was at the very edge of
running out of core.

I've been RTFMing (or would that be RingTFM) all afternoon but have yet to
find any references to "Not enought core".  Could somebody tell me what that
means specifically and/or what I can do about it, or at least tell me where in
the FMs I can find the information?

Almost forgot: I'm running SCO Xenix 2.0.4.  The program is small model with
               the -i switch, but medium model without it.  :-)

Thanks a lot.
-- 
Roger Murray
"Look ma!  No ihnp4!"  :-)
UUCP: ...!{randvax,sdcrdcf,ucbvax}!ucla-cs!cepu!ucla-an!remsit!rem
ARPA: cepu!ucla-an!remsit!rem@CS.UCLA.EDU

tif@cpe.UUCP (09/16/88)

Written  9:59 pm  Sep 12, 1988 by remsit.UUCP!rem in cpe:comp.unix.xenix
>I added the first one and put in added a few statements so I could
>check to see that it worked.  I then put in the second function (which calls
>the first) and everything compiled away just fine but when I went to run it,
>I got "Not enough core".
>Almost forgot: I'm running SCO Xenix 2.0.4.  The program is small model with
>               the -i switch, but medium model without it.  :-)

Once again (this is one of the questions that is up for election to be
added to news.newusers :-).  No offense, I've just answered it at least
a half-dozen times):

	1)  DGROUP is the limiting factor that will cause linking
	    problems or load-time problems.

	2)  (in small model) DGROUP contains everything but actual code.
	    We all know that both the code and ALL the data must be < 64K.
	    That's code + data < 64K if no -i option, or
	    code < 64K AND data < 64K if you use the -i option.

	3)  (In medium model) Code may be > 64K, data must be < 64K.  We
	    already knew that too.

	4)  (In large model) Code may be > 64K, ONLY UNITIALIZED GLOBAL
	    DATA may be > 64K, all other data (static, constants, initialized
	    globals, and stack) MUST BE < 64K.

	5)  (In huge model) The ONLY difference between huge and large is
	    that a single item (i.e. array) may be > 64K.

	6)  (In large model) If static + constants + initialized globals < 64K
	    then the linker will succeed.  Stack must be < (64K - static -
	    constants - initialized globals) for the executable to successfully
	    load.

In summary, in your case, it means that all the stuff in your program
fits inside of 64K.  But when the linker added the stack space it went
over 64K.  The linker doesn't report this, rather it shows up when the
executable is loaded (I mean executed).

Possible solutions are
	1.	go to large model, unitiliazed global data will be
		placed in a different segment.  That may be enough.
	2.	Reduce your stack size (-F #) where # < 0x1000.  Only
		you can decide if this is an option.
	2.	use -Gt##, try something between 32 and 256 for ##.
		Any global data larger than ## bytes will be put in
		a different segment.  Smaller ## are more likely to
		succeed but cause slower executables.

			Paul Chamberlain
			Computer Product Engineering, Tandy Corp.
			{convex,killer}!ninja!cpe!tif