Mail Archives: djgpp/2009/02/02/18:00:42
Hi guys,
On Feb 2, 1:16=A0pm, Eli Zaretskii <e DOT DOT DOT AT gnu DOT org> wrote:
> > Date: Mon, 2 Feb 2009 02:01:27 -0800 (PST)
> > From: Levent Yavas <mlist DOT DOT DOT AT yahoo DOT com>
>
> I'm using djgpp (gcc 2.95.2) for quite some time on my
> old 8Mb 386dx40. I'm using it as a learning tool for
> dos programming, so, optimizations aren't required.
If optimizations aren't required, you may be better off using the old
LCC for DOS (3.6?) or maybe CC386, which isn't an optimizing compiler.
Even Turbo C++ 1.01 is good for 16-bit code. OpenWatcom without
optimizations (-od) is pretty darn fast too.
> I have to select fastest but most bugfixed version of
> djgpp program combination.
You want fastest? As in compile speed or output or both? Well, first
let me state the obvious: any 486 (or 586, etc.) is faster than a
386. However, even I would be too lazy / dumb to bother upgrading.
Second, make sure to read the FAQ. The best speedup is running a small
cache (e.g. SMARTDRV, NWCACHE, UIDE, LBACACHE, etc) and small RAM disk
(VDISK, TDSK, XMSDSK, SHSURDRV) for %TMPDIR%. Third, it's hard to say
which GCC is least buggy. I can only guess 3.4.6, but that's probably
a bit too slow for your needs. (Something seemed to slow down a lot
after 3.2.3. And since 2.95.3 it got much bigger and slower, not
exactly sure why.) Actually, by default DJGPP uses "-mtune=3Dpentium",
which bloats it up a bit with alignment, which I'm not sure is helpful
for 386s. You can either edit your "specs" file (not recommended) or
manually always use "-march=3Di386". Honestly, I'm not sure GCC has ever
cared as much about real 386s. Most GCC versions I've tried actually
run slower if *not* using "-mtune=3Di686". And as long as you use "-
mtune" (or "-mcpu" for other versions), it will run on any 32-bit cpu,
even 386. So try "-mcpu=3Di686" and see if it helps. Actually, to be
honest, it'd be maybe? better if you (or somebody) recompiled GCC with
"-march=3Di386". Ideally, that would run faster. Of course, in reality,
it depends. But hey, it might be worth trying.
It's true that 2.7.2.1 is fast and small, but it only targets 486s (at
best). A lot of people wanted better optimizations and PGCC and EGCS
were born. Only with 2.8.1 did GCC finally support 586s. Later on
(April 1999, I think), EGCS were fully integrated as *the* GCC
version, and that turned into 2.95 (and 2.95.3 was the last of that
branch). But 3.02 was slower and bigger once it was finally released.
(To be fair, it was probably better too.) C++ support has gotten
better over time too, so I don't think exceptions work with 2.95. But
you've indicated no interest in that, so that simplifies things.
(GNU's internal C++ ABI has changed at least twice, i.e. some object
files would have to be recompiled if transferred between certain
versions.)
> Are there any incompatibilities with gcc-2.95.3?
C++ support is weaker (e.g. exceptions). No C99. No -mintel-syntax / -
masm=3Dintel. No optimizations beyond 686 or K6 (e.g. no P3, P4, AMD64,
etc). No Objective-C++ support. No GNAT/Ada support (this was before
that was integrated into the main branch) nor G77 / G95 Fortran. Also,
it has to be said, some code won't compile (but all GCCs have that
problem, people just never update their code).
> I suppose i can use latest versions of
> rhide, make and cwsdpmi.
>
> my list is:
> v2/djdev203.zip
> v2apps/rhid15ab.zip
> v2gnu/bnu219b.zip
> v2gnu/mak3791b.zip
> v2misc/csdpmi5b.zip
Use the latest? Yes, you *can*, but you're not. :-)
http://gd.tuwien.ac.at/pc/dos/djgpp/beta/v2/djdev204.zip
http://ap1.pp.fi/djgpp/rhide/rhide15cb.zip
http://gd.tuwien.ac.at/pc/dos/djgpp/beta/v2gnu/mak381b.zip
http://clio.rice.edu/djgpp/csdpmi5b_u.zip
> I suggest GCC 2.7.2. If you don't need C++, 2.7.2 was the leanest and
> meanest GCC version in the West.
As mentioned, some code won't compile with 2.7.2 (although for a long
time Linux kernel 2.2.x needed it exclusively). Actually, I think
2.7.2 was buggy, and 2.7.2.1 was the bugfixed version. In fact, DJ has
no such older versions on his site anymore. And only 2.95.3 is both
old enough and modern enough to have been compiled with Win2k fixes.
(Okay, maybe not an issue for you, just saying ...). Anyways, Eli
actually uses 2.8.1 / 2.03p2 on his P166 (which I use 3.4.4 / DJGPP
2.04 on my P166). My 486 has 2.95.3 / DJGPP 2.03p2 (and P166 too as a
backup). There really is almost no perfect answer.
> You need the version of Binutils released approximately during the
> same time frame as the GCC version you will choose. Other versions of
> Binutils are not 100% guaranteed to work correctly with that GCC
> version.
The MOSS DOS extender (circa 1996) was cross-compiled from Linux, and
it used GCC 2.7.2 and BinUtils 2.6, if that tells you anything (i.e.
what versions were modern at the time). 2.9 was when Intel syntax was
(finally!) supported. Similarly MMX and 3dnow! was added around that
time. I think 2.11 added SSE2. Personally, I use 2.16.1 with GCC
2.95.3. Standard EMX apparently uses GCC 2.8.1 (although C-only 3.0.4
binaries exist) with GAS 2.6 (although old deprecated FPC 1.0.10 DOS
+OS/2 EMX has 2.9.1, which is good for having 686+ CMOV.. support).
Just to be clear (although I don't think anyone besides me is
interested), I have a minimal GCC package (2.95.3 / 2.16.1 / 2.03p2 w/
Make, RM, CWSDPMI, WMEMU) that can fix packed on one 1.44 MB floppy
and only takes 6 MB of space (or 3.5 if UPX'd). It's pretty small and
fast. So you can indeed get by with only minimal stuff if all you want
is a simple C compiler. I should probably upload it to my site, but I
still need to bundle it a bit better as well as gather all sources for
my latest changes (mostly done). Actually, I forget, I did recompile
that for "-Os -march=3Di386", but that was mostly for smallest size (no
stinkin' alignment). ;-) Then again, that was via 4.2.3, and I
think 4.3.2 improved -Os a bit (which had regressed since 3.4.4).
Okay, enough blathering from me (for this thread, anyways) ....
- Raw text -