Mail Archives: djgpp/2002/02/18/16:30:06
> TurboC needs a lot less compile time for the same
> file(10 times less approx.) , and it is also a
> FASSSTER environment when you compare it to RHIDE.
> It also uses a lot less memory.
>
> ¿Why? ¿So high is the price we must pay for 32-bit
> programming?
More recent versions of GCC have been obsessed with
getting every tiny fraction of the potential performance
possible. Each new version has added optimizations
which take memory to perform.
A 386 will not benefit from many of these optimizations,
and would run acceptably with an older version of GCC.
If you don't need new features, you might consider finding
the oldest version of the tools you can find. They tend
to consume much less memory (which is your biggest challenge).
> I suppouse that efficiency is not one of the targets
> for gcc compiler.
It assumes that run time efficiency is all that is important
and that compile/build performance is not important. This
has been the case with every release of GCC I can remember,
since the 1.9 release days.
> I'm very happy with DJGPP, but only when I try to use
> it in my old 386 I think that maybe it is better to
> program in TurboC in that environment.
If developing small programs which easily fit in 64Kbytes,
I would agree. If you need to move outside the small memory
model and start messing with ugly "far" pointer extensions,
then you should stick with a 32-bit compiler. Code portability
is important - well written code will run fine on multiple
platforms - and DJGPP helps encourage portability.
> My 386 has only 2MB memory, perhaps it is the worst
> environment where DJGPP has runned in. ;-)
During V2.00 development I used to routinely test on a 1Mb 386SX
system. Compiles were still slow, but bearable.
With only 2Mb of memory you might need to tune your CWSDPMI settings
to maximize DPMI memory; there is also a balance between disk cache
and DPMI memory which you would need to evaluate. Since conventional
memory can be used as DPMI memory in situations such as yours, it's
important to unload as many DOS programs/drivers/TSRs as possible.
Avoid using EMM386 if possible for better performance.
I would suggest with newer GCCs you would want to use CWSPARAM to
modify "Minimum Application memory before 640K paging" to be 2048Kb
(so your system would always page in the 640K region). This might
increase your DPMI memory from 768K (assuming a 256K cache) to 1200K.
Such a large percentage increase might improve compile performance.
This, combined with older GCC and binutils and you might find
32-bit programming much more fun.
- Raw text -