Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!super.upenn.edu!eecae!nancy!umix!umich!mibte!gamma!ulysses!allegra!alice!tve From: tve@alice.UUCP Newsgroups: comp.arch Subject: Re: SPARC Message-ID: <7456@alice.UUCP> Date: Tue, 17-Nov-87 23:39:01 EST Article-I.D.: alice.7456 Posted: Tue Nov 17 23:39:01 1987 Date-Received: Sat, 21-Nov-87 06:46:27 EST Organization: AT&T Bell Laboratories, Murray Hill NJ Lines: 43 1) SPARC has nothing to do with CRISP. SPARC essentially is Berkeley RISC modified and extended to suit the "real" world. 2) The only SPARC implementation available today is the Fujitsu gate array (details have been posted). I have the data sheet, the bus interface is *horrible* unless you want to use the chip *exactly* as Sun does. Future versions by Fujitsu may be different (rumor). 3) The performance of SPARC implementations does *NOT* necessarily scale with clock rate! The Fujitsu gate array does LOADs in 2 cycles (I-fetch, data-read) but STOREs in 3 cycles (I-fetch, i-don't-know-what, write-data). The data sheet doesn't say anything about that, but the Fujitsu rep. explained it. It has to do with the funny bus interface. I forgot the exact reason. All this to say, that another *implementation* of the SPARC *architecture* may use a different number of cycles, more busses or god knows what. 4) There is no way the Fujitsu SPARC chip can emulate 68020 code at 7MIPS (whatever that means). I think the confusion arises from the "source code compatibility" between Sun-3 (68020) and Sun-4 (SPARC) claimed by Sun. All that means, is that source code used on Sun-3 can be compiled for Sun-4 "unaltered". 5) The Fujitsu SPARC chip number is MB86900. There is a floating point controller to interface the SPARC cpu with Weitek 1164 and 1165 chips. It's number: MB86910. 6) Flame ... Question: how many pins do you think the SPARC cpu has? Answer: 256! Question: how big do you think the package is? Answer: 2 inches on a side! Question: is this a joke? Answer: No! Thorsten von Eicken ...!research!tve tve@research.uucp PS: Please correct if I mistated anything. I'm not trying to make the SPARC look bad ... nor good ... nor ...