Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!uunet!mcsun!ukc!edcastle!aipna!uk.ac.ed.aipna!awb From: awb@uk.ac.ed.aipna (Alan W Black) Newsgroups: comp.os.minix Subject: Re: Compiler comparisons (object code) Message-ID: <3675@aipna.ed.ac.uk> Date: 14 Dec 90 11:26:31 GMT References: <1640@sun13.scri.fsu.edu> <722@philica.ica.philips.nl> Sender: news@aipna.ed.ac.uk Reply-To: awb@uk.ac.ed.aipna (Alan W Black) Organization: Dept of AI, University of Edinburgh, Scotland Lines: 78 In article <722@philica.ica.philips.nl>, adrie@philica.ica.philips.nl (Adrie Koolen) writes: |>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. |> |> |> 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? |> |>Adrie Koolen (adrie@ica.philips.nl) |>Philips Innovation Centre Aachen This is exactly the problem with GCC 386. I can't offhand remember if its 4K or 8K (or bigger -- as I've said before Richard Tobin did the difficult bit, and he's away at the moment) alignment for the data segment but there is rather a nasty space in there which is rather a large percentage of small programs. Also there is always basic floating point signal handlers linked in. There also has been mention about gcc compiled programs having a large chmem size. This is because the basic gcc a.out format has no size associated with it, so when it is converted it is simply set to 65535 which could be far too large, or even too small but some figure was required. You should really tune that yourself. I suppose we never really considered worrying about this size problem as GCC is such a win when compiling big programs, itself, emacs, various prologs, lisps and ml. And big programs were the reason for porting it. Maybe I've adopted too much of the gnu philosophy if I say I don't care enough about the lost memory :-) I have been thinking about recompiling the whole of 1.5 with gcc and I think then I might begin to care. But at present if you're worried about space use bcc, if you are worried about time use gcc -O and if the program will compile to greater than, say 64K with bcc, it'll probably be smaller with gcc Alan Alan W Black 80 South Bridge, Edinburgh, UK Dept of Artificial Intelligence tel: (+44) -31 225 7774 x228 or x223 University of Edinburgh email: awb@ed.ac.uk