Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!mcsun!hp4nl!charon!dik
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.arch
Subject: Re: SPARC implementation or architecture
Message-ID: <3354@charon.cwi.nl>
Date: 18 Apr 91 01:36:54 GMT
References: <1991Apr17.183822.7681@elroy.jpl.nasa.gov>
Sender: news@cwi.nl
Organization: CWI, Amsterdam
Lines: 37

In article <1991Apr17.183822.7681@elroy.jpl.nasa.gov> david@elroy.jpl.nasa.gov (David Robinson) writes:
 > [I hope this doesn't start any religious wars about which RISC is "better"]
 >                        Is it an implementation issue such as the
 > fab process used effecting gate delays, or the design process
 > such as complete custom vs cell libraries, or design trade offs
 > such as pipeline depth?
Some of the differences come from this.  Although I can not find it right now
in the Cypress SPARC manual, I know that on the SPARC some instructions take
more than 1 clock cycle (stores for example).  I think however that that is
not the main source of the difference.  But at least this difference is not
architecurely defined.
 >                          If not an implementation issue then is
 > it a fundimental architecture issue such as lack of integer
 > multiply and divide or register windows vs large flat register file.
There are also implementation issues working here.  I do not think that
register windows play a big role; I would assume that overall the use of
register windows vs. the use of a flat register file would balance (in
some cases one is better, in other cases the other).  Lack of instructions
can play a role.  I do not know how important integer multiplies are for
the SPEC marks, but they are decidedly slower on the SPARC (note that some
future SPARCs will have integer multiply operations).  In this case it is
also interesting to see that the new HP PA 1.1 architecture has integer
multiply, and that it gives a big speed up on some codes.
On the other hand, I would think that the absense of condition codes on the
MIPS might have a detrimental effect on the SPEC marks.  HPPA might score well
because of its calculate+conditional-annul.

Other influences are from the compiler technology.  And perhaps more.

For my own, very personal, opinion, I think Acorn has the best ideas with
respect to RISC architecure.  But that is of course not relevant here!  (Well, I
think m88k comes second, amd29k third, mips fourth, sparc fifth and hp sixth.)
But that is my opinion on architecture, I do not think I would advise buying
workstations in this order!
--
dik t. winter, cwi, amsterdam, nederland
dik@cwi.nl