Mail Archives: djgpp/2009/02/12/19:15:29
Hi,
On Feb 12, 12:16=A0am, "Charles Sandmann" <cwsd DOT DOT DOT AT earthlink DOT net> wrote:
> "DJ Delorie" <d DOT DOT DOT AT delorie DOT com> wrote in message
>
> news:200902120335 DOT n1C3Z6fC031082 AT envy DOT delorie DOT com...
>
> >> I was referring to the last GCC 1.x release - and it's been so long I
> >> don't
> >> remember what it was. =A0Sometime around 1990?
>
> > The GCC project maintains a historical timeline of gcc releases here:
> >http://gcc.gnu.org/releases.html
>
> Cool page. =A0Around 1992. =A0I guess that would be GCC 1.42. =A0Source
> distribution of 1.8MB (compared to 6.8MB for 2.7.2.3), and earlier 1.x gc=
c
> releases were less than 1MB source distribution.
>
> Nice to have references for things that far back so memory can't get too
> corrupted :-)
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/djgp=
p/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=3Di386-go32-msdos --target=3Di86-pc-msdos". Third, I
think you actually need "make xgcc cc1 cccp CC=3Dgcc CFLAGS=3D'-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) .... ;-)
- Raw text -