Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!mailrus!uwmcsd1!nic.MR.NET!shamash!nis!ems!quest!zeno!gene
From: gene@zeno.MN.ORG (Gene H. Olson)
Newsgroups: comp.arch
Subject: Re: How the Japanese will win the MIPS wars with SPARC
Summary: Summary of responses, author's conclusions.
Message-ID: <91@zeno.MN.ORG>
Date: 16 Sep 88 05:33:06 GMT
References: <58@zeno.MN.ORG>
Reply-To: gene@zeno.MN.ORG
Organization: Smartware Consulting, Minneapolis, MN
Lines: 82

Two weeks ago, I published the original article on this subject.
The original was deliberately pompus to (sic) sparc controversy.
I delayed in publishing a followup until I felt the ripples had
died down.

That article asserted that the Japanese would dominate the RISC
markets because they would produce highly competetive non-proprietary
SPARC products while US companies would cash in on customers locked
into their proprietary architectures.  

There were some very helpful responses pointing out that the MIPS
architecture is currently second and third sourced.  They did not
mention if MIPS was `open' in the sense that alternative competing
implementations of the MIPS instruction set are welcomed.  I assume not.

The wide availability of second source chips seriously weakens
my original argument.   And I for one am encouraged that MIPS
may continue to compete on price/performance in the marketplace.

However:

*	The SPARC architecture is fully `open' in the sense that anyone
	may design a competitive processor or system of any sort without
	bothering to defeat architectural patents, and with the full
	co-operation of the original designers.
	
	So far as I know, this is a unique event in the history of
	computer design.  It parallels (in my opinion) the openess
	of the UNIX operating system.  Not that anyone cares, but I
	predicted the similar success of UNIX some 10 years ago.

*	So long as an architecture is kept proprietary, the owner of
	that architecture may choose at some point to cut off second
	sources, jack up prices, and go for profits.
	
	Intel chose to do this with the 386, and Motorola did so with
	the 68020 and 68030.  Intel is currently engaged in a
	widely-publicised court battle with AMD to break their
	existing second source agreement covering the 386.

*	It is not terribly important who has the fastest current clock
	speed, instruction timings, or read/write cycle counts unless
	these features are locked in by the instruction set.

	All of the RISC chips are being sold on what they will be in
	a few years.  Everyone is predicting 100 MIPs or so.  Currently
	available chips are only hints of what is to come.

*	There was a heated discussion for awhile about register windows.
	No one pointed out that the SPARC architecture accesses register
	windows only with explicit instructions, that the architecture
	spec requires only two of them (one for user mode, one for
	software traps), and that they need not be otherwise used.

	SPARC offers you the option of register windows.  If they don't
	help in some situations (they seem to work well in others) there
	is no reason you need use them.  Since only two of them are
	required, there is no serious penalty if they are unused by an
	implementation.  Its clearly a win-win situation.

-------------- Bottom line

Both manufactures and consumers of RISC chip products should be
aware that we have dawned upon a new age in computer architectures.
There will be at least one widely implemented, truly `open' standard.
Any proprietary architecture (however well established) will be
at a disadvantage to a well-informed consumer.

DEC has been forced to loosten its grip on VMS and the VAX,
IBM failed in promoting a PC-based 360 architecture (there was one),
and Sperry (now UNISYS) is doing most of its expansion into UNIX.

It happened in the operating system business.  It *will* happen
in the RISC processor business,  and if you are foolish enough
to ignore the trend,  you will be left behind.

The Japanese will be there in force.  The USA can be there too.

Its your choice.

Gene H. Olson                     amdahl!bungia!zeno!gene
Smartware Consulting
gene@zeno.mn.org