Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!uunet!mcsun!hp4nl!phigate!philica!adrie
From: adrie@philica.ica.philips.nl (Adrie Koolen)
Newsgroups: comp.os.minix
Subject: Re: Compiler comparisons (object code)
Message-ID: <722@philica.ica.philips.nl>
Date: 12 Dec 90 12:29:45 GMT
References: <1640@sun13.scri.fsu.edu>
Reply-To: adrie@beitel.ica.philips.nl (Adrie Koolen)
Organization: Philips TDS, Innovation Centre Aachen
Lines: 58

In article <1640@sun13.scri.fsu.edu> nall@sun8.scri.fsu.edu (John Nall) writes:
>Running both standard Minix 1.5.10 and Minix-386 (on different partitions),
>and having recently installed GCC (with many thanks to Alan Black and friends),
>and having also done some testing with the new ANSI compiler, I had the unique
>opportunity to compare the four compilers on my system.  I found the following
>comparisons rather interesting, and thought I would share them....
>
>John Nall
>nall@sun8.scri.fsu.edu
>
>OBJECT			OBJECT		OBJECT		OBJECT		OBJECT
>PROGRAM 		SIZE		SIZE		SIZE		SIZE
>NAME                    (ACK)		(ANSI)		(BCC)		(GCC)
>----------------------------------------------------------------------------
>dosread		10888		13920		14740		32800
>libpack		 4400		 7912		11020		28704
>libupack		 1908		 2756		 2884		22560
>readclock		 5948		 9232		 8924		22560
>term			 4390		 6328		 5468		24608

I'm puzzled by the fact, that the GCC object files are so big! I'm using
GCC 1.37.1 under Minix-Sparc and it's supposed to be the same as the 386
version apart from the back-end, which is of course Sparc specific. The
middle three programs are useless for the SparcStation, but the first and
the last program I have compiled under Minix-Sparc with GCC and got the
following object size. `dosread', which doesn't work properly because of
byte ordering problems, is 19224 bytes, and `term' compiles to an object
of 5464 bytes. These objects are stripped, so no symbol table is appended.

Now, the Sparc processor, being a RISC processor, generally needs bigger
object files than a CISC processor (like the 386). So I'd expect the GCC
386 object files to be somewhat smaller than the Sparc versions.
I suspect, that the exorbitant size of the GCC object files is not because
of size-inefficient code generation of the GNU compiler, but due to
link or library problems.

On the SparcStation, object are linked with the data segment immediately
following the text segment. Only word alignment takes place. Also, the
symbol table (when not stripped) is stored directly after the (initialized)
data segment. Maybe, the GCC object files, mentioned in the table, are not
stripped or use excessive (4K?, 8K?) alignment? Under SunOS, the first 8K
of a process are not used (trap null pointer dereferences). Maybe also on
the GCC 386 object files?

On Minix-Sparc, I support floating point. When a small program calls
printf, a lot of floating point subroutines are linked in, whether it is
used or not!

If term.c is compiled to term.o (`cc -c term.c'), how big is term.o? My
term.o (on a SparcStation) is 5314 bytes. That is with symbol table,
of course.

I can't believe, that the GCC 386 back-end is that inefficient! Compile the
programs to assembly with the compilers and then compare the size. I like
to know where the big sizes come from.

Adrie Koolen (adrie@ica.philips.nl)
Philips Innovation Centre Aachen