Path: utzoo!attcan!uunet!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!sunybcs!boulder!grunwald
From: grunwald@foobar.colorado.edu (Dirk Grunwald)
Newsgroups: comp.arch
Subject: lets start another processor war - i860 vs RIOS
Message-ID: <22257@boulder.Colorado.EDU>
Date: 14 Jun 90 16:40:15 GMT
Sender: news@boulder.Colorado.EDU
Reply-To: grunwald@foobar.colorado.edu
Distribution: comp
Organization: University of Colorado at Boulder
Lines: 51


well, there's been too much talk about Mac OS's and trivia. Time to
get back to what comp.arch is good at.

I just finished reading most of the architecture articles in the IBM
journal about the RIOS/America architecture. I've also read articles &
microprocessor manuals for the i860.

The frank opinion I got was that the i860 was a total barf for
compilers and people. You can certainly manage the pipeline, but it's
a royal pain. Witness that the i860 has been available for a year, and
no one has an (available) compiler that gives you more than about 5MF
for the 40Mhz parts, while the RIOS is getting >7 with a 20Mhz part
and >10 with a 25Mz part. The additional interlocking logic on the
RIOS simplifies compiler and programming tasks considerably. You also
get the nice addition of correct exceptions.

The only things that would seem to stop the RS/6000 from sweeping the
Intel juggernaut off the earth is:

	(a) Intel will sell you chips, IBM will sell you systems
	(b) RIOS is four chips + cache + everything else, Intel
	    is one chip + more cache + everything else

The questions I had from their articles was the expansion path for the
architecture. Certainly, you can crank up the clock - the part's only
doing 25Mhz in the market place now, but allegedly, they're going to
produce parts that give you 50 -> 100 SPECmarks within a year or two,
which is either a conservative doubling or not-so-conservative
(without more integration) quadrupling of clock speed (& memory &
cache).

What I'm wondering is, can they stick in more FXU's or FPU's without
changing the architecture semantics. Right now, the single FXU handles
load/stores for the FPU as well as the integer core insns. There's
interlocking between the two for precise exceptions. With the current
wires to memory, you could probably add another FXU -- you can fetch 4
insn's at once, and there's currently four functional units. Clearly,
everything isn't going to be kept maximally busy w/o more insn's being
fetched, for the straight-line basic-blocks, the additional FXU might
make an improvement.

So, for people who've look at the architecture, does it look like you
could toss in another FXU and still keep precise exceptions? If not,
would the FPU/FXU blocking make the advantages of an additional FXU
moot? Likewise, insn fetch - would you really need one insn fetched
per functional unit, or would ``sharing'' the bandwidth between the
branch/extra FXU be an advantage?

Dirk Grunwald -- Univ. of Colorado at Boulder	(grunwald@foobar.colorado.edu)
						(grunwald@boulder.colorado.edu)