Date: Fri, 16 Sep 94 22:48:26 JST From: Stephen Turnbull To: mfeldman AT seas DOT gwu DOT edu, djgpp AT sun DOT soe DOT clarkson DOT edu Subject: memory utilization? From: eliz AT is DOT elta DOT co DOT il who quotes mfeldman as writing: > Error: not enough memory to run go32! > > A "mem" command executed from the inner shell gives: > > 655360 bytes total conventional memory > 655360 bytes available to MS-DOS > 173744 largest executable program size (sure, the editor is loaded) This shouldn't happen, as far as I know. If you are using DJGPP's "system()", everything except GO32 itself should be swapped out. I'm not sure about functions like "exec()", however. If my swapping hypothesis is correct, the new process should have about 478 - 130 = 348KB available to it. mem.exe would take up about 48KB, and when COMMAND.COM is resident, it uses about 90KB as I recall, leaving 210KB. I don't know where the remaining 35-40KB disappeared to, though. > Looks like my extra 7meg is not being used. How do I make this happen? > Anything that runs in real mode, including nonreentrant DOS extenders (which GO32 is; I don't know if there are any reentrant DOS extenders, due to the fact that DOS is nonreentrant), must fit under the 1MB line; in practice, that means under 640KB. What GO32 does for you is to load the user program into that 7MB of extended memory; it can't do the same trick for itself. It has to run in real mode part of the time to inteface with DOS. (That's what Eli said, but I find my explanation easier to understand, and sufficiently complementary to his to be worth including.) DJGPP eats up about 130K of *conventional* memory for each DJGPP-compiled program. The extended and virtual memory are only used for the protected- mode code of the program you wrote, but go32 (the extender) runs as DOS program, and as such uses conventional memory below 640K. > BTW - after doing setupgpp, before invoking our editor, > > 478672 bytes largest executable program size This is very low number. Try to nake it larger by moving things to the Bzzt. As of GO32 1.11.maint5, it was plenty. I regularly run make in an environment with 448KB program memory (my Japanese font and front end processor does not like to be loaded high). Recursive makes are impossible. To recapitulate the accounting Charles Sandmann gave me for GO32 1.11.maint2, (1) a new copy of GO32 requires 180KB to set itself up. (2) GO32 leaves 130KB in memory when running a child process. (3) Thus, running GCC requires 130KB (the inactive GO32 for GCC) + 180KB (new GO32 for CPP, CC1, AS, LD, etc), or 310KB. (4) Running make requires 2*130 + 180 = 440KB, and (5) A recursive make (make calling make) requires 3*130 + 180 = 570KB. (6) Theoretically with QEMM, DESQview, an ATI Graphics Ultra, and VIDRAM, you could run a recursive make from inside Emacs (700KB). Um, yup, I don't think so---this is just dreaming. So, 4 invocations of GO32 looks to be the practical limit. And since 478K is comfortably above 440KB, you should be able to run not just one but two recursive GO32s. upper memory (with Memmaker or QEMM's Optimize). You should be able to invoke at least 2 or even 3 DJGPP programs one from inside the other, otherwise you won't be able to even run Make. Eli Zaretskii Eli's advice is sound in any case. However, I suspect that you must being doing something strange inside your editor code to run into the problem. You should easily be able to recursively invoke system() twice from inside your editor. The only thing I can think of offhand is that you are calling the shell, which should be unnecessary---and the shell shouldn't use so much space anyway. So you should look at the source code for say GCC to see how that is done and compare it to your own, see if you can slim down the environment that's being passed a bit, etc. If the shell is the problem, and you have a big environment, you can get substantial savings over COMMAND.COM with a carefully tuned 4DOS. (Or NDOS from Norton, but modern 4DOS's (current revision is 5.0f) are much better than NDOS, which is 4DOS 4.01 with the serial numbers filed off (legally, it's licensed).) If you tried to run make inside your editor, you'd get that message; but I wonder if you can really free as much as 100KB more by using memmaker or Optimize. It also doesn't explain why running mem gives that small a free space. The only other thing I can think of off hand is that GO32 has an option which allows you to specify that extended memory should also be swapped out, but that shouldn't have anything to do with this case. +-----------------------------------------------------------------------+ | Stephen Turnbull | | University of Tsukuba, Institute of Socio-Economic Planning | | Tennodai 1-chome 1--1, Tsukuba, Ibaraki 305 JAPAN | | Phone: +81 (298) 53-5091 Fax: +81 (298) 55-3849 | | Email: turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp | | | | Founder and CEO, Skinny Boy Associates | | Mechanism Design and Social Engineering | | REAL solutions to REAL problems of REAL people in REAL time! REALLY. | | Phone: +81 (298) 56-2703 | +-----------------------------------------------------------------------+