tve@alice.UUCP (11/18/87)
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 ...rick@seismo.CSS.GOV (Rick Adams) (11/19/87)
In article <7456@alice.UUCP>, tve@alice.UUCP writes: > 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". Of course Sun's claim about running Sun-3 code unaltered on a Sun 4 is utter fantasy. Many programs that run fine on a Sun 3 will not run on a Sun-4 without major modifications. (And of course many programs that run a Sun-3 will indeed run fine on a Sun -4. The point is that they all won't.) The exact claim is "Even though the Sun-4 family is based on a powerful new architecture, Sun has maintained 100% source-code compatibility with Sun-2 and Sun-3 product families" Sun's response to that is that the programs are not portable if they won't run on a Sun 4. However, thats not the issue. Marketing claims that any program that runs on a sun3 need only be recompiled to run on a Sun-4 it doesn't say anything about passing lint with NO ERRORS (I have never seen a real program that didn't get some sort of lint error). ---rick