Path: utzoo!attcan!uunet!wuarchive!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!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: <734@philica.ica.philips.nl>
Date: 14 Jan 91 09:59:02 GMT
References: <1640@sun13.scri.fsu.edu> <722@philica.ica.philips.nl> <729@philica.ica.philips.nl> <1926@Terra.cc.brunel.ac.uk>
Reply-To: adrie@beitel.ica.philips.nl (Adrie Koolen)
Organization: Philips TDS, Innovation Centre Aachen
Lines: 28

In article <1926@Terra.cc.brunel.ac.uk> eesrajm@cc.brunel.ac.uk (Andrew J Michael) writes:
>Your wish is my command.  I can't get at the nm output on this machine, but
>doing a compilation on the 386 and doing an ls -l of the object files gives:
>
>  sort.o -       gcc: 10975   bcc: 9224
>  dhrystone.o: - gcc: 2739    bcc: 2581

That's interesting. The sort and dhrystone executables were much larger under
bcc (26624 and 21504 text sizes) than under gcc (19456 and 15360 text sizes).
As you can see, BEFORE linking, the bcc objects were slightly SMALLER than the
gcc object files! Do you use the same linker with bcc and gcc? I guess not.
I also assume, that you use different libraries. How do they compare in size?

Anyway, the sizes of the two object files under Minix-Sparc are:

  sort.o:	17056
  dhrystone.o:	 3805

As I already expected, the Sparc objects are somewhat bigger than the 386 gcc
and bcc object files! I must say that a relatively big part of the objects is
the symbol table. sort.o, for instance, has some 10KB of text + data and a
symbol table of 7KB!

I still think that the big sizes of the 386 executable are due to bad linking
and/or big library files (the Minix-Sparc libc.a is 156KB).

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