delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1994/09/16/15:29:28

Date: Fri, 16 Sep 94 22:48:26 JST
From: Stephen Turnbull <turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp>
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                        |
+-----------------------------------------------------------------------+

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019