Message-Id: <m0yQAQR-000S3EC@inti.gov.ar>
Comments: Authenticated sender is <salvador AT natacha DOT inti DOT gov DOT ar>
From: "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
Organization: INTI
To: "Paul Derbyshire" <pderbysh AT usa DOT net>, djgpp AT delorie DOT com
Date: Fri, 17 Apr 1998 09:45:11 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: RHIDE and pentium cc1plus
In-reply-to: <9hAZ.3264$sN3.543198@news21.bellglobal.com>
Precedence: bulk

"Paul Derbyshire" <pderbysh AT usa DOT net> wrote:

> There's no love lost between RHIDE and the PGCC 1.0.1 cc1plus.exe. Sometimes
> when launched in RHIDE, this cc1plus will inexplicably choke and complain about
> "virtual memory" being "exhausted", even though there're 23 physical megabytes
> free and 62 virtual. When run from the command prompt, cc1plus works fine, even
> though it has exactly the same memory available (since RHIDE, like all
> DJGPP-compiled software, swaps itself out entirely when it launches a subtask).
> This means I have to enter long commandlines manually, capture errors with
> redir and manually look them up in the sourcefiles, instead of being able to
> handily track down the error by simply selecting it in the RHIDE output window.
> 
> It can't possibly be malloc failure, since there's no way in hell cc1plus is
> using over 62 megs in compiling! Besides, even if it were using 62 megs it
> would have the exact same problem at the command prompt, which it does not.
> 
> So what is wrong with PGCC? What other circumstances will make it emit that
> error message? Environment space perhaps? RHIDE will fill its environment and
> that of any subtask with $RHIDE_COMPILE_FLAGS and so forth, so that could be
> it, except I just don't see why cc1plus would use environment space as internal
> storage.

Well, it seems to be a problem of gcc in general, perhaps this particular cc1 
is even worst. The FACT is that gcc is sensitive to PHYSICAL memory, don't ask 
me way or how, I really don't understand the effect. For some tasks gcc really 
needs PHYSICAL memory and all the virtual memory in the world doesn't help a 
bit. 
A good example in my system is that W95 some times eats enogh physical memory 
to make fail my compiling, under plain DOS the same is when RHIDE uses 2Mb more 
than normally (for example: too much editor opened and InfView with a huge info 
file, or debug info loaded in memory).
gcc 2.8.0 seems to be less sensitive to this problem.
I don't understand why it happends because gcc uses malloc (or I'm wrong in it, 
could it use sbrk() for something?). Perhaps is some fragmentation effect, in 
this case:

Does anybody tried to link gcc with the DJGPP alpha malloc?

Greetings, SET
------------------------------------ 0 --------------------------------
Visit my home page: http://set-soft.home.ml.org/
or
http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org
ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013