Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!oliveb!intelca!mipos3!omepd!mcg
From: mcg@omepd (Steven McGeady)
Newsgroups: comp.arch
Subject: Re: Yield of core-MIPS chips [MIPSCo yield? && Other Issues]
Message-ID: <3347@omepd>
Date: 1 Apr 88 19:09:59 GMT
References: <2904@omepd> <751@esunix.UUCP> <2089@ho95e.ATT.COM> <10170@steinmetz.steinmetz.ge.com> <629@ra.rice.edu>
Reply-To: mcg@iwarpo3.UUCP (Steve McGeady)
Organization: Intel Corp., Hillsboro
Lines: 76


Three weeks ago I posted an article with the above title, asking, among
other things, that we discuss in this group a broader range of issues
regarding processor architectures and their success than just (e.g.)
conditions codes or not, scoreboarding or not, or UNIX-applicability or
not.  Other than a few small factual responses to the yield and
silicon foundary question, none of the topics I suggested have been
raised, and this discussion has devolved into another tedious RISC. vs.
CISC debate!

The questions I initially asked where (briefly):

	1) Who manufactures MIPSco's silicon?, with details.

This was partially answered, both by MIPSco and by others, with names of
the foundries ("strategic partners") that MIPSco uses, and other information
such as yield was understandably not present.

	2) How does MIPSco keep apace of silicon technology?

The argument was presented by MIPSco that their foundaries and strategic
partners have competitive silicon technology which they can exploit.
This begs the question to some extent of whether a foundary can be
competitive with captive technology development, but that's likely to be
a matter of opinion.

	3) What is the availability of compilers, assemblers, debuggers)
	   on VAXen, SUN's, and PC's?

Absolutely NO ONE has addressed this.  John Mashey politely did address it
in private mail, but nobody else seems to care.  John pointed out that
MIPSco's compilers (a major part of their competitive posture) are available
only on MIPSco boxes.  This harkens back to the days of captive development
systems for microprocessors, which I thought had been finally vanquished.
I wonder why there is no discussion here of this.

	4) What is the complexity of integrating a MIPSCo chip set
	   into a system?  What amount and kind of support HW is needed?

I got a brief response in private mail from MIPSco saying "No harder than
anybody else".  Being a software type, I don't know all the right probing
questions to ask, but surely there are others out there who either: a)
have experience with this; or b) are curious and know the right questions.
(E.g. memory bus i'face: how wide, deep, long, strong?; cache: how fast,
expensive, hard, necessary?)

	5) What does it take to make an architecture successful?

I posited a (somewhat circular) answer to this that I thought would
engender some discussion.  I am disappointed.  If you all ignore this
message too, I will assume that my interest in these questions is
perverse and crawl back into my hole.


Finally, One respondent picked up on my reference to some "somewhat
inelegant" aspects of the 386 (along with some inelegant aspects of the
MIPSco chip).  I pointed this out only to be (or appear to be) somewhat
objective.  Let there be no mistake: the 80386 pays my (meager)
paycheck every month, and even though I'm working on unrelated
architectures directed at different problem sets, and regardless of how
I truely feel about the 386 architecture, which you won't be able to
find out without knowing me much better,  I am daily grateful to the
386 and its progenitors for the continued rise in the value of my Intel
stock holdings.

And, in case you hadn't figured it out, this and all other communications
by me are my opinion alone, and in no way represent the opinion of anyone
else, least of all my employer, and are presented without the explicit review
or approval of that employer, something that will probably get me in big
trouble someday.


S. McGeady
Intel Corp.
mcg@iwarp.intel.com, mcg@omepd.intel.com,
...!intelca!omepd!mcg, ...!tektronix!ogcvax!omepd!mcg