Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!caip!topaz!think!nike!lll-crg!hoptoad!farren
From: farren@hoptoad.uucp (Mike Farren)
Newsgroups: net.micro.ns32k
Subject: Re: Re: Re: Re: National's 32332 (Apples and oranges really)
Message-ID: <869@hoptoad.uucp>
Date: Tue, 17-Jun-86 21:53:53 EDT
Article-I.D.: hoptoad.869
Posted: Tue Jun 17 21:53:53 1986
Date-Received: Thu, 19-Jun-86 09:22:12 EDT
References: <865@hoptoad.uucp> <423@cbmvax.cbmvax.cbm.UUCP>
Reply-To: farren@hoptoad.UUCP (Mike Farren)
Distribution: na
Organization: Nebula Consultants in San Francisco
Lines: 42

daveh@cbmvax.cbm.UUCP (Dave Haynie) writes:
>Well, first of all, you should be comparing implementations of the same
>compiler on both machines.

  Agreed, this would be the best of all alternatives.  Don't know of an
instance of the SAME compiler on 8086 and 68000, though.  Note that the
UniSoft cc seems to be quite efficient, as far as 68000 compilers go;
the same program that resulted in a 19.5K file with UniSoft created a
32K (!) file on a SUN-3.

> I think the point of the above article was that the 68xxx and 32xxx
> instruction sets will provide better overall compiled code, all other
> things being equal.

  At any event, there was general agreement (with which my experience
agrees) in a discussion in net.arch that comparable 68K programs will be
approx. 20% larger than 8086 programs, simply because of the larger
number of bytes used by the respective instructions.  I have no data for
the 32K series - I remember it being a very nicely designed instruction
set, though.

> Besides testing the memory efficiency of the compiled code, take
>a look at the execution efficiency; I'd expect the 68000 to do quite a bit
>better than the 8086 at the same clock speed with comparable compilers,
>especially with program and data spaces over 64K bytes.

On this point, I have to agree, although you have to consider that clock speed
is one of the most meaningless measures you can possibly come up with.  The
point that I would make here is that immediate rejection of Intel parts 
simply because they have faults is, perhaps, the silliest position I've seen
taken in a religious war in a long time.  Certainly, the Intel processors
have deficiencies - what processor doesn't?  The Intel processors also have
one SCREAMING advantage --- there are one hell of a lot of them out there.
As a (currently) independent programmer, I'd rather make a lot of money by
writing for a machine with faults but a huge market than starve by only
writing for the hottest architecture available.  Not that I would mind
seeing the 68K or 32K processors take off, mind you - it would make my job
a lot easier.  Ain't gonna happen this century, though.

----------------
Mike Farren
hoptoad!farren