Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!sparc!skk From: skk@sparc.UUCP (Stuart Kreitman) Newsgroups: comp.sys.next Subject: Re: RISC vs. CISC -- SPECmarks Message-ID: <28@sparc.UUCP> Date: 26 Apr 91 04:27:18 GMT References: <27fa3350.6bc2@petunia.CalPoly.EDU> <71367@brunix.UUCP> Organization: /etc/organization Lines: 35 > >Say no to hacks, say no to RISC (at least in SPARC-like incarnations). > A religious opinion flying in the face of industry history? I agree SPARC ain't pure or holy. I have thought alot about the instruction set while writing assertions and tests on object file conformance to the SPARC architecture manual. However, SPARC and other ~RISC machines do perform well. The people at Sun, Sparc International and elsewhere are building the first true multivendor shrink wrap UNIX architecture after Xenix/286. >In addition, the 68040 has built-in support for multi-processing. >Which of the RISC chips does? (This is a real question). If there is Er, you mean an atomic load-store? Version 7, page 80 >any, then that's the one NeXT is most likely to choose, since I would You mean the people at NeXT, or the sign out front? NeXT was cool when they had that expensive real estate near XEROX PARC, but they've since moved uptown. >guess multiprocessing is a more general solution to performance >problems than any RISC-hack can offer, and thus I would suspect NeXT A guess is right. I'll share the truly broad brush with you: multiprocessing sometimes works, but I've already slaved on 2 multiprocessors that were failures (TOPS-10 and MegaFrame) >is putting a higher priority on that than on RISC. What if it were only a marketing decision? > >Just my 0.02$ > >Ronald Another dude who blames stuff on "them"