Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

djgpp on 386

58 views
Skip to first unread message

Levent Yavas

unread,
Feb 2, 2009, 5:01:27 AM2/2/09
to dj...@delorie.com

Hi!

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.

I have to select fastest but most bugfixed version of
djgpp program combination. gcc-2.95 series was quite
popular at time, in spite of gcc-3.x. So, I suppose
2.95.3(this is latest in 2.95 isn't it?) is good
canditate as a fast and correct compiler for 386. (If
some older versions that are faster and
non-problematic let me know)

And what djgpp dev kit, binutils versions that I have
to select? Are there any incompatibilities with
gcc-2.95.3? 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

Please make me suggestions

Levent Yavas


Eli Zaretskii

unread,
Feb 2, 2009, 2:16:09 PM2/2/09
to dj...@delorie.com
> Date: Mon, 2 Feb 2009 02:01:27 -0800 (PST)
> From: Levent Yavas <mlis...@yahoo.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.
>
> I have to select fastest but most bugfixed version of
> djgpp program combination. gcc-2.95 series was quite
> popular at time, in spite of gcc-3.x. So, I suppose
> 2.95.3(this is latest in 2.95 isn't it?) is good
> canditate as a fast and correct compiler for 386. (If
> some older versions that are faster and
> non-problematic let me know)

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. All the versions after that simply
got fatter and slower. And on top of that, with 2.7.2 you could debug
optimized code without any major problems, something you cannot even
dream doing with GCC 3.x. The ability to debug optimized code was at
one time one the most attractive features of GCC (without it, you need
to test your software twice, or distribute unoptimized code), but
lamentably it was sacrificed on the altar of another 5% improvement in
code speed.

> And what djgpp dev kit, binutils versions that I have
> to select? Are there any incompatibilities with
> gcc-2.95.3?

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.

> I suppose i can use latest versions of rhide, make and cwsdpmi.

Yes.

Rugxulo

unread,
Feb 2, 2009, 5:55:33 PM2/2/09
to
Hi guys,

On Feb 2, 1:16 pm, Eli Zaretskii <e...@gnu.org> wrote:
> > Date: Mon, 2 Feb 2009 02:01:27 -0800 (PST)

> > From: Levent Yavas <mlist...@yahoo.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=pentium",
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=i386". 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=i686". 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=i686" and see if it helps. Actually, to be
honest, it'd be maybe? better if you (or somebody) recompiled GCC with
"-march=i386". 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=intel. 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=i386", 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) ....

Rugxulo

unread,
Feb 2, 2009, 7:56:52 PM2/2/09
to
Hi again,

On Feb 2, 4:55 pm, Rugxulo <rugx...@gmail.com> wrote:
>
> 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=i386", 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, I think I sorted everything out. Try it (if you dare,
mwahahahaa). ;-)

http://rugxulo.googlepages.com/djgpp203.7z (main file)
http://rugxulo.googlepages.com/djgpp203.txt (readme / changes)
http://rugxulo.googlepages.com/dj203lst.txt (list of all
files)
http://rugxulo.googlepages.com/dj203-7z.txt (.BAT to recreate
the .7z)

Of course, you need "7zdecode" to unpack the .7z itself, and that can
be found here (w/ srcs):

http://rugxulo.googlepages.com/7ZDEC.ZIP

That actually has several compiles (for variety), but I suggest the
OpenWatcom one since it's smallest (although it's SFNs only, but in
this case that doesn't matter, I made sure everything is 8.3 clean).
So you can even put the decoder on the same floppy as the main archive
(which I consider a "good thing"). Note that I've tested it on my 486
w/ 8 MB RAM total, and it does decompress correctly in under three
minutes. (Previously I was using UHarc, which is slightly better but
closed src, needed 24 MB of RAM, and was slower.)

BTW, full srcs for everything available here (including p7zip if you
want/need it to tweak the archive itself):

http://rugxulo.googlepages.com/

P.S. The biggest file (i.e. the main problem file in trying to cram it
all on a floppy) is CC1.EXE. Just look at this comparison (default
compiles of DJGPP GCCs):


GCC2953B.ZIP

lib/gcc-lib/djgpp/2.953/cc1.exe
723,620 (1,621,504) Dec,25,2001 12:13:34p [Deflat]


GCC302B.ZIP

lib/gcc-lib/djgpp/3.02/cc1.exe
958,333 (964,816) Nov,21,2001 05:02:04p [Deflat]

(Hmmm, that one is obviously UPX'd)

cc1 exe 2,446,848 Nov,21,2001 05:02:04pm A...


GCC304B.ZIP

lib/gcc-lib/djgpp/3.04/cc1.exe
957,482 (964,020) Feb,21,2002 03:02:28p [Deflat]

cc1 exe 2,442,240 Feb,21,2002 03:02:28pm A...


GCC323B.ZIP

lib/gcc-lib/djgpp/3.23/cc1.exe
1,230,968 (2,753,536) Apr,30,2003 07:10:20p [Deflat]


GCC336B.ZIP

lib/gcc-lib/djgpp/3.36/cc1.exe
1,333,981 (2,903,040) May,07,2005 03:12:12p [Deflat]


GCC344B.ZIP

libexec/gcc/djgpp/3.44/cc1.exe
2,178,611 (4,235,264) May,28,2005 12:09:08p [Deflat]


GCC401B.ZIP

libexec/gcc/djgpp/4.01/cc1.exe
2,499,536 (4,836,864) Jul,17,2005 12:02:26p [Deflat]


GCC412B.ZIP

libexec/gcc/djgpp/4.12/cc1.exe
2,725,126 (5,309,952) Mar,11,2007 02:57:38a [Deflat]


GCC423B.ZIP

libexec/gcc/djgpp/4.23/cc1.exe
2,560,828 (2,591,704) Feb,12,2008 12:24:36a [Deflat]

cc1 exe 5,761,024 Feb,12,2008 12:24:36am A...


GCC432B.ZIP

libexec/gcc/djgpp/4.32/cc1.exe
3,527,392 (7,431,168) Sep,01,2008 06:40:54p [Deflat]


Wow, makes me want to downgrade my P166 to use 3.3.6 instead. I'll
have to check to see if there's much internal difference worth
anything. :-P

DJ Delorie

unread,
Feb 2, 2009, 8:14:20 PM2/2/09
to dj...@delorie.com

> http://rugxulo.googlepages.com/djgpp203.7z (main file)

Keep in mind that if you distribute GNU binaries, as you're doing
above, the GPL *requires* that you include all the sources for those
binaries on the same site as the binaries. The GPL doesn't permit you
to depend on someone else's site, unless you've made some sort of
legal arrangement to maintain GPL compliance.

Rugxulo

unread,
Feb 2, 2009, 10:25:51 PM2/2/09
to

Rugxulo

unread,
Feb 2, 2009, 10:55:22 PM2/2/09
to
Hi (yet again),

On Feb 2, 6:56 pm, Rugxulo <rugx...@gmail.com> wrote:
>
> http://rugxulo.googlepages.com/7ZDEC.ZIP
>
> That actually has several compiles (for variety), but I suggest the
> OpenWatcom one since it's smallest (although it's SFNs only, but in
> this case that doesn't matter, I made sure everything is 8.3 clean).
> So you can even put the decoder on the same floppy as the main archive
> (which I consider a "good thing"). Note that I've tested it on my 486
> w/ 8 MB RAM total, and it does decompress correctly in under three
> minutes. (Previously I was using UHarc, which is slightly better but
> closed src, needed 24 MB of RAM, and was slower.)

I forgot to mention that you probably have to stub the 7ZDECWAT.EXE
binary via either STUBX (D3X) or STUBIT (WDOSX) since it needs DPMI.
(Pure DOS usually doesn't have DPMI except DR-DOS 7.03.) Just a small
nit, but something to be aware of. (I need to make a note of that on
my page. It was a last minute change I forgot about, doh.)

Rod Pemberton

unread,
Feb 3, 2009, 3:38:24 AM2/3/09
to
"Rugxulo" <rug...@gmail.com> wrote in message
news:5a1646f8-6338-4467...@v39g2000pro.googlegroups.com...
>
> [on webpage] "all these srcs take 23 MB of space, so I'm lucky it fits my
Google Pages allotment!! "
>

You could link to them stored elsewhere:

Rapidshare (free file sharing)
free PER FILE max file upload: 200Mb (deleted after 90-days without
download)
http://rapidshare.com/agb.html
http://rapidshare.com

TinyUrl (short links)
http://tinyurl.com/

000webhost.com (free web hosting)
free 1500Mb disk space, 100 Gb data transfer
http://www.000webhost.com/

You'll have to read 000webhost's term's. IIRC, it's free because they "data
mine," i.e., analyze user connections to your website...

> Anyways, here's the sources for everything

Maybe a post with all links to comp.os.msdos.programmer... ? I think there
are a few guys there who use DJGPP but don't post here.

If you're still reading the OpenWatcom NGs, you might post there too...
:-) It might draw some scorn, but IIRC there are a few there who used to
post here.

I occasionally see questions about DJGPP on other groups. When I recommend
posting here, no one ever takes my advice...

Webring's seem to be falling out of usage, but you might also think about
joining the WebRing's for DJGPP or Allegro.


RP


Rugxulo

unread,
Feb 3, 2009, 6:05:10 PM2/3/09
to
Hi,

On Feb 3, 2:38 am, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> "Rugxulo" <rugx...@gmail.com> wrote in message


>
> news:5a1646f8-6338-4467...@v39g2000pro.googlegroups.com...
>
> > [on webpage] "all these srcs take 23 MB of space, so I'm lucky it fits my
>
> Google Pages allotment!! "
>
> You could link to them stored elsewhere:

Well, I cleared up some space (and could even clear a little more), so
it's a non-issue at the moment. Just kinda shocking that a file meant
for putting on a single floppy needs 20 times that for the sources.
(Of course, that's due to me not removing non-DOS parts of GCC and
BinUtils, which I'm not sure is worth trying since I'm afraid I'd
accidentally remove something important). At least I switched
to .tar.bz2 for most stuff, so that saved some space. And, as
mentioned, I used that instead of other better compression formats
because DJTAR is more useful (in-place decompression, SFN and LFN
friendly, extract to screen, poor man's wildcards, etc). ;-)

> Rapidshare (free file sharing)
>  free PER FILE max file upload: 200Mb (deleted after 90-days without
> download)http://rapidshare.com/agb.htmlhttp://rapidshare.com

So many websites have broken links, it's quite annoying. And trying to
get archived files from the WayBack Machine ends up truncating them
(apparently) at 99%. I don't even honestly know what Google Pages
gives for bandwidth, but since I never get any e-mails about my site,
I'm not worried. ;-)

BTW, years ago some people mentioned making a small DJGPP distro (e.g.
George Foot with 2.7.2.1) but never finished due to various issues. It
was even suggested that DJ himself mirror it so they wouldn't have to
have all sources. Granted, I'm fairly certain he's not interested
(already mentioned this to him before). I just thought an extra small
GCC C compiler was useful. ;-)

> 000webhost.com (free web hosting)
>   free 1500Mb disk space, 100 Gb data transferhttp://www.000webhost.com/


>
> You'll have to read 000webhost's term's.  IIRC, it's free because they "data
> mine," i.e., analyze user connections to your website...

I think a lot of companies do things like that. Of course, I'm less
concerned than you are. But anyways, sites like that seem to disappear
pretty abruptly without warning, which is annoying.

> > Anyways, here's the sources for everything
>
> Maybe a post with all links to comp.os.msdos.programmer... ?  I think there
> are a few guys there who use DJGPP but don't post here.

I thought about posting there, but I wasn't sure if anybody would
really care. And since this was DJGPP-related, I stuck it here (and
still wonder whether anyone cares, heh).

> If you're still reading the OpenWatcom NGs, you might post there too...
> :-)   It might draw some scorn, but IIRC there are a few there who used to
> post here.

Well, it's a similar issue with OpenWatcom. You can cram a small 16-
bit target C compiler on one floppy too. I've mentioned all that (esp.
to Harry Potter, who wanted a small version to transfer to his old
486). I would've cross-posted there, but this is only DJGPP-related.
Still, the whole idea is the same: remove unnecessary tools (DMPOBJ,
DOS4GW, WASMR), include only C stuff, use 7-Zip or UHarc, etc.

> I occasionally see questions about DJGPP on other groups.  When I recommend
> posting here, no one ever takes my advice...

I don't know whether DOS users are just anarchists, lazy, or just busy
busy busy with their own projects. (I think they're just really strong-
willed, independent, and always working on something.) It's hard to
convince them to do anything! (And I should know.) ;-)

> Webring's seem to be falling out of usage, but you might also think about
> joining the WebRing's for DJGPP or Allegro.

Nah, I don't think I get much traffic anyways. ;-)

Levent Yavas

unread,
Feb 6, 2009, 6:37:57 AM2/6/09
to dj...@delorie.com

Thank you very much all guys & gals ...

I installed:
djdev201.zip
bnu27b.zip
gcc2721b.zip
csdpmi5b.zip
mak3791b.zip
rhide15b.zip, rhid15ab.zip, rh1501b.zip

This configuration ran fine with makefiles. But rhide
crashes when starting. Actually it wasn't run really
fine with my older djgpp setup, crashes when opening
some source file. But why it selects a particular
djgpp setup I don't understand. Reinstalled some newer
development versions of rhide over not working one but
with no success. Aren't that latest versions supposed
to be most bug fixed? I'll try previous versions
instead.

Rugxulo thank you very much for your detailed
explanations and djgpp package.
I'm not tried your djgpp version, but I'll definitely
try it.

Levent Yavas

CBFalconer

unread,
Feb 6, 2009, 11:07:29 PM2/6/09
to
Levent Yavas wrote:
>
> Thank you very much all guys & gals ...
>
> I installed:
> djdev201.zip
> bnu27b.zip
> gcc2721b.zip
> csdpmi5b.zip
> mak3791b.zip
> rhide15b.zip, rhid15ab.zip, rh1501b.zip
>
> This configuration ran fine with makefiles. But rhide crashes when
> starting. Actually it wasn't run really fine with my older djgpp
> setup, crashes when opening some source file. But why it selects a
> particular djgpp setup I don't understand. Reinstalled some newer
> development versions of rhide over not working one but with no
> success. Aren't that latest versions supposed to be most bug fixed?
> I'll try previous versions instead.

Why are you using djdev201? That is obsolete. Consider the
current version, which includes djdev203, from the home port. See
delorie.com/djgpp

Please do not top-post. Your answer belongs after (or intermixed
with) the quoted material to which you reply, after snipping all
irrelevant material. See the following links:

<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/> (taming google)
<http://members.fortunecity.com/nnqweb/> (newusers)

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

Levent Yavas

unread,
Feb 7, 2009, 9:11:57 AM2/7/09
to dj...@delorie.com

> Why are you using djdev201? That is obsolete.
> Consider the
> current version, which includes djdev203, from the
> home port. See
> delorie.com/djgpp
Actually I'm using it because of possible
incompabilities. Thanks!

> Please do not top-post.
Sorry...

Note: rhide14 work fine. I suppose rhide15 has some
windows fixes that not work quite right.

Levent Yavas



Rugxulo

unread,
Feb 10, 2009, 12:15:10 AM2/10/09
to
Hi,

On Feb 6, 5:37 am, Levent Yavas <mlist...@yahoo.com> wrote:
>
> Rugxulo thank you very much for your detailed
> explanations and djgpp package.
> I'm not tried your djgpp version, but I'll definitely
> try it.

I *just now* compiled GCC 2.7.2.3 from stock GNU srcs (via GCC 2.95.3)
for "-O2 -march=i386" if you prefer that. (It runs faster than 2.95.3
and is smaller although obviously not as advanced. Apparently DJGPP
never had a stock compile except of 2.7.2.1, without Win2k fixes) You
can install the DJGPP203.7Z file and "bin\rm @manifest/gcc2953b.mft"
and then "unzip GCC2723B.ZIP" on top of it. GCC 3.4.4 (compiled by me
specifically for -march=pentium") runs at least four times slower on
my P166 (at least compiling TDE 5.1v). I don't know why, Haifa
scheduler? As Eli mentioned, "2.7.2" has some advantages (assuming it
likes your code).

http://gcc.gnu.org/releases.html

GCC 2.7.2.3 August 22, 1997
GCC 2.8.1 March 2, 1998
GCC 2.95.3 March 16, 2001

http://rugxulo.googlepages.com/gcc2723b.zip (600k, no Info
docs)
http://rugxulo.googlepages.com/gcc2723s.tbz (5.3 MB, stock srcs
from GNU ftp)

Actually, I earlier compiled 2.7.2.1 on my P166 yesterday (and even
applied the newer patches) using Martin Stromberg's old GCC2721S.ZIP
(which is all truncated to 8.3, which is what gave me the idea to try
in bare DOS *without* LFNs). It can even compile itself. (I wonder if
386/486 optimizations regressed since then but haven't tested. Some
people also claim .EXE size has gone up ever since, which is actually
fairly true.) In particular, the annoying part there is needing a
bunch of separate utils that my mini EZGCC-ish package doesn't have
(bash, mv, cp, sed, update, djecho copied to echo, touch). Also, the
whole "make LANGUAGES=c" doesn't work and goes ahead trying to build
CC1OBJ.EXE anyways (which wastes space on an already low-space HDD due
to both CC1OBJ and CC1OBJ.EXE being made, etc). Building "make stage1"
etc. doesn't work by default, probably 'cause I'm missing some other
tools. I found it easier to just setup the "new" compiler manually and
then rebuild. (2.7.2.1 can reputedly even build 2.95.3.) And the
default CFLAGS used -g (debug info), which I find unnecessary (for me,
I don't want to debug it, only build!) and that wastes space too. UPX
helps. I should've either used my FreeDOS FAT16 partition (4k
clusters) instead of my DR-DOS partition (16k clusters, ugh) and/or
used "diet -D *.c" (compress) plus "diet -Z2" (load TSR to decompress
if necessary). Anyways, I know you (Levent) probably won't build it
yourself, just mentioning it anyways. ;-)

P.S. There's an old libc5 Linux build of DJGPP cross tools (GCC 2.7.2,
BinUtils 2.7) with DJDEV 2.00 (although I assume 2.03p2 would work
too) below (maybe good for anybody still using BasicLinux or Slackware
4.0 on old hardware or similar). IIRC, Quake used something like that
(2.7.2.1 or similar) with some hand-written assembly tuned for Intel
Pentium FPU. I forget where they cross-compiled from, probably was
NeXT or whatever (not Linux). Of course, they used *nix-y sbrk() which
was default in 2.00 beta (right?? I know DJ and CWS have answered this
before, search the archives if you're interested).

http://www.ibiblio.org/pub/linux/devel/msdos/

Eli Zaretskii

unread,
Feb 10, 2009, 4:31:19 AM2/10/09
to dj...@delorie.com
> From: Rugxulo <rug...@gmail.com>
> Date: Mon, 9 Feb 2009 21:15:10 -0800 (PST)

>
> GCC 3.4.4 (compiled by me specifically for -march=pentium") runs at
> least four times slower on my P166 (at least compiling TDE 5.1v).

Like I said: 2.7.2 is the leanest, meanest GCC in the West.

> I don't know why, Haifa scheduler?

Who knows? I guess the main reason is that being lean and mean is no
longer a worthy goal in the eyes of GCC developers as much as it was
before.

> I wonder if 386/486 optimizations regressed since then but haven't
> tested. Some people also claim .EXE size has gone up ever since,
> which is actually fairly true.

I challenge anyone who cares to show a test case where a real-life C
program (not one of those "benchmarks" prepared solely to show off
optimizer features) runs more than 10% faster under GCC 3.x or 4.x
than when compiled by GCC 2.7.2.

Me, I will trade 10% speedup for the ability to debug optimized code
any time. To say nothing of 4-fold compilation speedup.

Thanks for making a new build of GCC 2.7.2.3 available. Too bad it
didn't support DWARF-2 debug info, but that disadvantage pales in
comparison with its advantages.

Charles Sandmann

unread,
Feb 10, 2009, 8:23:59 PM2/10/09
to
"Eli Zaretskii" <el...@gnu.org> wrote in message
news:u4oz2s...@gnu.org...

> Like I said: 2.7.2 is the leanest, meanest GCC in the West.

Someday I'd like to build a GCC 1.9 version again and compare on
compile speed. I remember build times being much less with the 1.9
versions (but optimizations much less, of course). But that experience
was on non-x86 Unix platforms...

I did have a single floppy GCC 2.2.2 development environment based
on DJGPP 1.08 once (before any compressed exes were available).


DJ Delorie

unread,
Feb 10, 2009, 8:32:43 PM2/10/09
to dj...@delorie.com

gcc 1.9?

The first djgpp-built gcc was 1.37.

Maybe you meant djgpp 1.09?

Charles Sandmann

unread,
Feb 11, 2009, 10:20:37 PM2/11/09
to
"DJ Delorie" <d...@delorie.com> wrote in message
news:200902110132....@envy.delorie.com...

> gcc 1.9?
> The first djgpp-built gcc was 1.37.
> Maybe you meant djgpp 1.09?

I was referring to the last GCC 1.x release - and it's been so long I don't
remember what it was. Sometime around 1990? But that was on Unix and VMS
iron - and trying to port my code from those systems to DOS is what got me
started with DJGPP - around the 1.07 or 1.08 timeframe. Back when a 486 was
a really fast machine, challenging the $100K+ systems.


DJ Delorie

unread,
Feb 11, 2009, 10:35:06 PM2/11/09
to dj...@delorie.com

> I was referring to the last GCC 1.x release - and it's been so long I don't
> remember what it was. Sometime around 1990?

The GCC project maintains a historical timeline of gcc releases here:

http://gcc.gnu.org/releases.html

Charles Sandmann

unread,
Feb 12, 2009, 1:16:03 AM2/12/09
to
"DJ Delorie" <d...@delorie.com> wrote in message
news:200902120335....@envy.delorie.com...

Cool page. Around 1992. I guess that would be GCC 1.42. Source
distribution of 1.8MB (compared to 6.8MB for 2.7.2.3), and earlier 1.x gcc
releases were less than 1MB source distribution.

Nice to have references for things that far back so memory can't get too
corrupted :-)


Rugxulo

unread,
Feb 12, 2009, 7:00:52 PM2/12/09
to
Hi,

6.8 MB is due to wimpy .tar.gz and can be shrunk to smaller with
better compression (e.g. 7-Zip). Heck, the DJGPP-specific part is much
smaller, and for example the GCC2721S.ZIP file is a little over 4 MB,
so you obviously don't need everything (.texi, .1, Changelog*, /
winnt/, /mips/, /sparc/, /arm/, /m68k/, etc). Heck, just stripping C
comments would probably shrink it a lot (if you're low on space or
just didn't need 'em).

I think it's been said that up to 50% of C is usually spent in
preprocessing (unlike Pascal with its pre-compiled units). C and
Pascal can both be parsed in one pass although for optimizations I
guess newer ones do more than that. I just wonder why 2.95.3 -O0 can
be relatively fast but 4.3.2 -O0 is relatively slow. "It does more
now." But why? If all you want is unoptimized, fast-compiled output
for testing, what the heck is it doing?? From the archives DJ said (in
1996) that he could build GCC on his 486/66 w/ 16 MB RAM in half an
hour. My P166 took about ten minutes the other day building 2.7.2.x,
so I guess that's about right. But that was back in ancient
"historical" times. Nowadays GCC is quite complex to build.

It's also been mentioned that (Open)Watcom is faster compiling due to
being x86 only and doesn't need a separate assembler (it
generates .OBJ directly). And Borland is similarly fast also due to
much weaker code generation. Other compilers don't even try to
optimize (LCC and CC386). And even TinyCC is fast, one-pass with
integrated assembler and linker with weaker optimizations too (and
very few outputs, even outputs ELF .o on Win32). So I dunno. At one
time GAS and LD were one-pass, right? But nowadays I don't think they
are (though not sure, honestly). I think they use more memory these
days to speed up everything (e.g. --reduce-memory-overheads uses old
slower, less mem algorithms).

P.S. Anyone ever tried DJ's 16-bit GCC hack? http://www.delorie.com/djgpp/16bit/

Well, it's 2.7.2.x, so I compiled it (with DJGPP of course) although
it's a little buggy IMO. But I can get it to work. Not sure what it's
really intended for, writing 16-bit .OBJ libraries for embedded
systems?? Still, it's cool. So you can grab it (with all patches and
utils except NASM plus ultra trivial test code) here:

http://rugxulo.googlepages.com/dj16bit.zip
http://rugxulo.googlepages.com/gcc2723s.tbz

A few notes: First, I had to manually tweak config.sub since DJ's
patch didn't work (although other two did). Second, I had to tell it
"sh configure --build=i386-go32-msdos --target=i86-pc-msdos". Third, I
think you actually need "make xgcc cc1 cccp CC=gcc CFLAGS='-s -O2' "
to compile it, and even then, you have to copy gstab.h to stab.h
(despite debugging not working anyways). Once built, I had to use
inline asm("..start:"); etc. a lot just to get NASM to cooperate else
it wouldn't build an executable. (On the bright side, DOS calls are
easy to use, which makes the lack of libs easier.) And strangely
enough, DJLINK needs G++, which I couldn't bootstrap with 2.7.2.x
(although I didn't look too closely), but I just used 2.95.3 for
building everything anyways. (Actually, you don't really need DJLINK,
it is hardcoded, but you can always -c compile to .OBJ and use
something else, e.g. Warplink, but that isn't portable, which I guess
was the whole point [originally cross-compiled on SGI].) Oh, and you
have to use DOS NASM because it can't shell the Win32 one (at least
for me, meh). Any NASM after 0.98.39 needs decent C99 support, which I
think only GCC 3.2.3 and later have. (Or at least I didn't get
anything older to work.), just FYI. NASM 0.97 compiles with 2.7.2.x
just fine.

Okay, enough ramblings (for now) .... ;-)

Rugxulo

unread,
Mar 5, 2009, 12:19:05 PM3/5/09
to
Hi,

Ah, I see, 1.35 was the first but was cross-compiled. And 1.37 was the
first to build on DOS itself.

http://www.delorie.com/djgpp/history.html

"The first version that made it big was djgpp 1.03, which can still be
found in a few shareware catalogs, even though 1.03 was pre-grok-
copyleft, and those shareware dealers are distributing it illegally."

Was this due to PharLap or something else? Anyways, just for laughs, I
accidentally found GCC 1.36 on Funet.Fi using "our own version of
'run386' (with source code - yes)", is that legal?? I don't think
anybody in their right mind wants to run it, though. ;-)

DJ Delorie

unread,
Mar 5, 2009, 12:41:46 PM3/5/09
to dj...@delorie.com

The problem with the oldest distributions was that not all sources for
all gnu utilities were included, that's all. It wasn't more nefarious
than that.

The history page is quite old; I doubt you can still find 1.03
anywhere.

Rugxulo

unread,
Mar 5, 2009, 4:23:33 PM3/5/09
to
Hi,

Well, I wasn't looking for it, just stumbled upon something by
wandering around a bit. Here's what I found (although I haven't tried
it, should I?):

ftp://ftp.funet.fi/pub/msdos/programming/gcc/

uchida.zip 1098 KB 6/17/1993 12:00:00 AM

Archive: uchida.zip 1123483 bytes 19 files
-rw-r--r-- 2.0 fat 93407 b- stor 9-Oct-90 20:48 gcc&/bine.lzh
-rw-r--r-- 2.0 fat 401336 b- stor 9-Oct-90 20:23 gcc&/bins.lzh
-rw-r--r-- 2.0 fat 146518 b- stor 9-Oct-90 17:47 gcc&/src/
binuty.lzh
-rw-r--r-- 2.0 fat 5503 b- stor 9-Oct-90 20:59 gcc&/src/
copying.lzh
-rw-r--r-- 2.0 fat 189193 b- stor 9-Oct-90 05:12 gcc&/src/gas.lzh
-rw-r--r-- 2.0 fat 59925 b- stor 9-Oct-90 05:14 gcc&/lib/libc.lzh
-rw-r--r-- 2.0 fat 61220 b- stor 9-Oct-90 05:20 gcc&/lib/math.lzh
-rw-r--r-- 2.0 fat 4149 b- stor 9-Oct-90 11:47 gcc&/lib/uty.lzh
-rw-r--r-- 2.0 fat 1235 t- defN 9-Oct-90 05:04 gcc&/makerule.gcc
-rw-r--r-- 2.0 fat 76827 b- stor 9-Oct-90 20:49 gcc&/usr.lzh
-rw-r--r-- 2.0 fat 33843 t- defN 9-Oct-90 12:19 contents
-rw-r--r-- 2.0 fat 1508 t- defN 9-Oct-90 12:03 inst.c
-rw-r--r-- 2.0 fat 7856 b- defN 9-Oct-90 12:03 inst.exe
-rw-r--r-- 2.0 fat 548 t- defN 9-Oct-90 12:20 install.bat
-rw-r--r-- 2.0 fat 31256 b- defN 21-May-89 22:14 lharc.exe
-rw-r--r-- 2.0 fat 1235 t- defN 9-Oct-90 05:04 makerule.gcc
-rw-r--r-- 2.0 fat 2350 t- defN 9-Oct-90 13:38 read.me
-rw-r--r-- 2.0 fat 26892 b- stor 19-Nov-90 12:32 xm.lzh
-rw-r--r-- 2.0 fat 24136 b- stor 9-Oct-90 05:54 xm/xm.lzh
19 files, 1168937 bytes uncompressed, 1121545 bytes compressed: 4.1%


(quoting READ.ME):

----------------------------------------------------------------------------------------------------------------
GCC ver 1.36 and related utilities for IBM-PC/AT 386
Oct 9, 1990
Yoshiaki Uchida

How to install

to install drive c: , run

inst c >install.bat

then execute install.bat

Please check the content of 'install.bat' created by inst.exe.


Update
Floating point subroutines are much better.
Bug fix in file - related functions like lseek().
many other functions.
Here is our own version of 'run386' (with source code - yes).
Distributing binary copies is free.

Bugs
In some case,
" run386 bin/ar dv xxx.a yyy.o "
cause segment error.

If you meet this bug, please use following procedure to avoid it.

1. make or go to working directory.
2. extract all objects in the library.
3. delete what you want to delete.
4. create new library for all rest object.

to do this, see the makefile in /gnu/libc.
It is used to make lib.a, but works only if you create 'object.def'.
For example,
ls *.o | sed "s/$/ \/" | sed "s/^/ /" >object.def
will of much help to you.

Occationary "run386 xxx" does not run if invoked by gmake or gcc.exe.
In this case, please create batch file using -n option of gcc.exe or
gmake.exe.

Usage of gcc.exe

gcc -?
shows brief comment.
gcc -n
shows commands what gcc.exe generated but do not execute them.
It is useful to create .bat file.

Options are read from file 'gnucc.cfg' then read from command line.

exmample

gcc -c *.c -O
compile all *.c files in current directry
create object (.o) files (-O option).
optimize (-O)

gcc -S foo.c -msoft-float
compile 'foo.c' but do not assemble it. Result is 'foo.s'.
object code run without FPU (-msoft-float)

gcc -ohello hello.c work.o -msoft-float
Compile hello.c, then link with work.o, to produce hello.exp.
This hello.exp is called from run386.exe (or xm.exe) as
run386 hello[.exp]


Usage of xm.exe (run386.exe)

is just like run386.exe of Phar Lap. But there is no options.

run386 /bin/foo

will serch /bin/foo first, if not found, then /bin/foo.exp


How to re-compile xm.exe

First unarc xm.lzh or xm.zip
then using TMAKE, TASM and TLINK of Borland, type

make xm.exe

which will create xm.exe.

Rename as run386.exe if you like compatible name with Phar Lap.
----------------------------------------------------------------------------------------------------------------

Sounds interesting, at least. :-)

DJ Delorie

unread,
Mar 5, 2009, 4:39:14 PM3/5/09
to dj...@delorie.com

That one isn't djgpp (or anything else related to what I've written),
and doesn't include all the GNU sources it should, so no, it's not a
legal distribution.

Rugxulo

unread,
Mar 5, 2009, 7:35:59 PM3/5/09
to
Hi,

Hmmm, weird. Okay, just thought it was curious. And it seems GCC 1.36
was released on September 24, 1989, so not exactly the most cutting
edge release. I think I'll stick to DJGPP. ;-)

0 new messages