Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site flairvax.UUCP
Path: utzoo!linus!decvax!decwrl!flairvax!kissell
From: kissell@flairvax.UUCP (Kevin Kissell)
Newsgroups: net.arch,net.micro.68k,net.micro.16k
Subject: Re: 16k vs 68k vs 432
Message-ID: <308@flairvax.UUCP>
Date: Tue, 3-Jan-84 21:44:29 EST
Article-I.D.: flairvax.308
Posted: Tue Jan  3 21:44:29 1984
Date-Received: Wed, 4-Jan-84 04:57:33 EST
Organization: Fairchild AI Lab, Palo Alto, CA
Lines: 32

First of all, the 432 is either a machine of the past or of the future,
The price is too high (but dropping) and the performance is apalling
(but improving).  Except for certain applications with heavy security
and/or reliability constraints, it is a very interesting and expensive
toy.  A revolution in semiconductor technology could change that, but
the benefits of such a revolution would apply equally well to simpler
architectures.

On to the less easy matter of 16k vs 68k.  The overall capabilities of
the two are really pretty similar, with a the 68k *generally* yielding 
somewhat better performance (depending, as always, on how one chooses 
one's benchmarks) and the 16k yielding better code density (ditto ditto).
The 32 bit internal architecture of the 16k (along with the ALU design)
make for faster multiplies and divides than the 68k, but the generality
and orthogonality of the 16k instruction set are expensive in microcode
cycles.  Exception handling in particular is significantly slower on the
16k than the 68k.  The 68k has more registers, but the 16k offers runtime
intermodule linkage.  The 16k has a much nicer MMU, but the 68k has those
handy postincrement/predecrement addressing modes.  Then there are the
quasi-religious issues: the 68k bus is asynchronous and unmultiplexed while
the 16k's is synchronous and muxed, the 68k is big-endian while the 16k
is little-endian, etc.  Which is better?  Neither, necessarily.  If you
want to build a simple, clean virtual memory machine, use the 16032/16082.
If you have a severe real-time problem, use a 68000 and *no* MMU.

		Kevin D. Kissell
		Fairchild Research Center
		Advanced Processor Development
		uucp:{ucbvax!sun decvax allegra}!decwrl!flairvax!kissell

		And yes, Fairchild is still planning to second-source 16k's.
		Not my department, though, so don't ask me when.