Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!rochester!PT.CS.CMU.EDU!K.GP.CS.CMU.EDU!lindsay
From: lindsay@K.GP.CS.CMU.EDU (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: Why is SPARC so slow?
Message-ID: <524@PT.CS.CMU.EDU>
Date: 15 Dec 87 22:07:01 GMT
References: <8809@sgi.SGI.COM> <6964@apple.UUCP> <8885@sgi.SGI.COM> <6993@apple.UUCP>
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 21

In article <6993@apple.UUCP> bcase@apple.UUCP (Brian Case) writes:
>On the other hand, *by definition,* the SUN
>approach is more scalable since there is at least some opportunity for
>scaling; a fixed-size register file cannot, by definition, be scaled.

There is an optimum size for a windowed register-set. The optimum may be
hard to locate precisely, but it has to exist. For example, there are
programs which don't overflow the window set of current chips. Building
chips with more registers, cannot speed those programs up. 

A more interesting question is, just what makes something scalable ?  Sun's
answer seems mostly to be "complexity" - they tried to minimize the chip
design time so that implementation can track the implementation technology.
But, of course, eventually, someone will build a complex implementation,
because they had all those gates left over ... and so it goes.

Hewlett-Packard just cancelled the project that was building a Spectrum out
of ECL. Reportedly they were $20M in. Does anyone know why ? Does this mean
anything for the ECL SPARC, or for scalability ?
-- 
	Don		lindsay@k.gp.cs.cmu.edu    CMU Computer Science