Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!rex!uflorida!haven!mimsy!jds
From: jds@cs.umd.edu (James da Silva)
Newsgroups: comp.os.minix
Subject: Re: Compiler comparisons (object code)
Message-ID: <28515@mimsy.umd.edu>
Date: 11 Dec 90 20:13:56 GMT
References: <1640@sun13.scri.fsu.edu> <28751@usc>
Sender: news@mimsy.umd.edu
Organization: University of Maryland, Department of Computer Science
Lines: 31

In article <28751@usc> kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes:
>In article <1640@sun13.scri.fsu.edu> nall@sun8.scri.fsu.edu (John Nall)
>writes:
>>NAME                    (ACK)		(ANSI)		(BCC)		(GCC)
>>----------------------------------------------------------------------------
> object size             smallest       bigger          bigger yet    biggest
>
>Can you please compare the speed of execution for these various
>binaries?  This would be very interesting information.

In general I would agree, but I guess that none of those programs is
particularly CPU bound, except perhaps for the libpack/libupack programs.

What I'd like to know is:
	- are these the .o sizes, or the final executable sizes?
	- whether you used bcc -0 or bcc -3? (I would guess -0 from the size)
	- whether you used the same libraries among the 16-bit compilers?

It's not the least bit surprising that the 32 bit code is much bigger than
the small model 8086 code; every integer and address in the program is
twice as big.

The most surprising numbers are that for the ANSI compiler versus ACK.  Has
the code quality gone way down, or is the libary or linker just different?
The best way to compare compiler code density is to look at the size of the
text segment in the .o files.  Is that what you did?

Jaime
...........................................................................
: domain: jds@cs.umd.edu				     James da Silva
: path:   uunet!mimsy!jds		    Systems Design & Analysis Group