Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site quad1.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!ittatc!dcdwest!sdcsvax!ncr-sd!hp-sdd!hplabs!sdcrdcf!psivax!quad1!jpm
From: jpm@quad1.UUCP (John McMamee)
Newsgroups: net.micro.ns32k
Subject: Re: Re: Re: Re: National's 32332 (Apples and oranges really)
Message-ID: <482@quad1.UUCP>
Date: Tue, 24-Jun-86 12:35:14 EDT
Article-I.D.: quad1.482
Posted: Tue Jun 24 12:35:14 1986
Date-Received: Sat, 28-Jun-86 02:29:24 EDT
References: <865@hoptoad.uucp> <423@cbmvax.cbmvax.cbm.UUCP> <2914@ihuxf.UUCP>
Organization: Quadratron Systems Inc, Sherman Oaks Ca.
Lines: 24

> > Executable file sizes, 6502 assembler program:
> > 
> > Intel, 8086, Microsoft C 3.0 -> 15110
> > Motorola 68000, UniSoft cc   -> 19500
> 
> A number of people have pointed out that executable file size
> is not a good indicator of memory resource requirements associated
> with a given machine.  For example:
> 
> 	. . . .
> 
> Why not avoid this distortion by comparing "object file" size, not
> "executable file" size.  That is, compile with the "-c" option.

That method fails as well because object modules can have a lot of
junk in them besides the code.  The only way to compare code size
is to get the code size figures (i.e. from size(1) on Unix, linker
maps on MSDOS, etc.).  Looking at file size, any sort of file,
just doesn't cut it.
-- 
John P. McNamee					Quadratron Systems Inc.

UUCP: {sdcrdcf|ttdica|scgvaxd|mc0|bellcore|logico|ihnp4}!psivax!quad1!jpm
ARPA: jpm@BNL.ARPA