Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!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: <729@philica.ica.philips.nl> Date: 9 Jan 91 14:19:02 GMT References: <1640@sun13.scri.fsu.edu> <722@philica.ica.philips.nl> <1921@Terra.cc.brunel.ac.uk> Reply-To: adrie@beitel.ica.philips.nl (Adrie Koolen) Organization: Philips TDS, Innovation Centre Aachen Lines: 46 In article <1921@Terra.cc.brunel.ac.uk> eesrajm@cc.brunel.ac.uk (Andrew J Michael) writes: >I have taken a couple of examples from my 386 - > > text data bss stack memory > > 21504 2048 11224 8192 42968 /usr/bin.old/dhrystone > 15360 1024 12284 8192 36860 /usr/bin/dhrystone > 26624 2048 2708 8192 39572 /usr/bin.old/sort > 19456 1024 4884 8192 33556 /usr/bin/sort > >In these cases the binaries in /usr/bin.old are compiled with bcc, and the >ones in /usr/bin with gcc. This still puzzles me. I use GCC 1.37.1 for Minix-Sparc and get: text data bss stack memory 12096 1096 12824 16384 42400 /usr/bin/dhrystone 12840 488 2936 60000 76264 /usr/bin/sort I've always been under the impression, that RISC processors need more instructions than a CISC processor to do the same job. The excess code is some 30%, depending on the exact processor (SPARC, MIPS, i860, 88000, etc.). Your examples show that the Sparc processor is significantly more (code) efficient than the 386!?! I still refuse to believe that. Give me the size of sort.o and dhrystone.o or, better yet, the `nm' list of sort.o and dhrystone.o (GCC includes a nm.c to list the symbol table of gcc generated object files). BTW, the total memory reported is not true. Minix-Sparc stores the text, data and bss segments right after eachother in memory. The stack segment however, is moved slightly to high-memory until it fills the last 4KB page entirely! So the `memory' number should be rounded to the next 4096 multiple. I assume, that Minix-386 does do something like that. The Sparc processor needs a large stack because it uses quite some stackspace to store register windows. The 386 text and bss segments have random (unaligned) sizes. The stacks are 8KB, but why are the sizes of the data segments a multiple of 1KB? >One should also be careful when comparing the sizes of text produced by gcc >since gcc regards strings as constants. And places them in the text, in stead of the data segment. Adrie Koolen (adrie@ica.philips.nl) Philips Innovation Centre Aachen