Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!pyramid!octopus!pete
From: pete@octopus.UUCP
Newsgroups: net.micro.ns32k
Subject: Re: Re: Re: National's 32332 (Apples and oranges really)
Message-ID: <206@octopus.UUCP>
Date: Mon, 16-Jun-86 16:14:09 EDT
Article-I.D.: octopus.206
Posted: Mon Jun 16 16:14:09 1986
Date-Received: Mon, 16-Jun-86 23:48:36 EDT
References: <746@usl.UUCP> <253@spar.UUCP> <2793@sdcrdcf.UUCP>
Reply-To: pete@octopus.UUCP (Pete Holzmann)
Followup-To: junk
Distribution: na
Organization: Octopus Enterprises, Cupertino, CA
Lines: 28
Summary: This is getting ridiculous!

In article <865@hoptoad.uucp> farren@hoptoad.UUCP (Mike Farren) writes:
>(a quote):
>>...when in compiled codes, especialy
>>'C', the National and Motorola instrucitons sets are much more efficient.
>
>Executable file sizes, 6502 assembler program:
>
>Intel, 8086, Microsoft C 3.0 -> 15110
>Motorola 68000, UniSoft cc   -> 19500
>
>This is more efficient?
>

Come on folks! Now we're *really* comparing apples and oranges! Small
executable files are only minimally affected by the compiled source code.
A *much* larger factor is how well the compiler/library manufacturer has
broken down the library into small chunks. The above numbers are really
a comparison of Microsoft's PC C library vs. UniSoft's Unix/68000 C library,
in terms of how small a subset of the full library is pulled in at a time.
Let's get back to apples vs. apples... and let's talk about something more
interesting and more obviously comparable, like support chips (whose
floating point is better?), etc...
file sizes are only minimal
-- 
  OOO   __| ___      Peter Holzmann, Octopus Enterprises
 OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014
  OOOOO \___/        UUCP: {hplabs!hpdsd,pyramid}!octopus!pete
___| \_____          Phone: 408/996-7746