Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!lll-winken!decwrl!nsc!amos
From: amos@nsc.nsc.com (Amos Shapir)
Newsgroups: comp.arch
Subject: Re: Compilers and RISC (was: '040 vs. SPARC)
Message-ID: <13591@nsc.nsc.com>
Date: 13 Feb 90 02:05:25 GMT
References: <1990Feb12.180813.6585@esegue.segue.boston.ma.us>
Organization: National Semiconductor, Santa Clara
Lines: 24
X-Hdate: 17 Shvat 5750

In article <1990Feb12.180813.6585@esegue.segue.boston.ma.us> colwell@multiflow.com (Robert Colwell) writes:
|In article <1990Feb11.221418.2634@esegue.segue.boston.ma.us> pardo@june.cs.washington.edu (David Keppel) writes:
|
|>[I always thought that the Intel 432 was an extreme example of why helpful
|>hardware can be a bad idea.  Bug-wise, consider the size of the errata list in
|>any modern CISC chip, and that according to a recent comp.arch posting there
|>are no known bugs in the current Moto 88000 chips. -John]
|
|You can't just take a snapshot comparison and conclude
|anything.  How many mask revs did it take Moto to get the 88K to a
|clean sheet?  Even if we knew that, and we knew how long the (say) 
|68040 will take, it's hard to extrapolate from two data points.

There's another factor - the design process has been largely automated
recently, and newer designs contain quite a fewer number of bugs than
earlier ones.  I don't know about 88K and 68k, but the NS32532 had reached
maturity in 3 revisions, while the NS32016 which is much less complicated,
took about 20 - just a few years ago.

-- 
	Amos Shapir
National Semiconductor, 2900 semiconductor Dr.
Santa Clara, CA 95052-8090  Mailstop E-280
amos@nsc.nsc.com or amos@taux01.nsc.com