Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!yale!mfci!colwell From: colwell@mfci.UUCP (Robert Colwell) Newsgroups: comp.arch Subject: Re: RISC Message-ID: <197@m2.mfci.UUCP> Date: Wed, 11-Nov-87 09:55:30 EST Article-I.D.: m2.197 Posted: Wed Nov 11 09:55:30 1987 Date-Received: Fri, 13-Nov-87 22:38:51 EST References: <1656@geac.UUCP> <863@winchester.UUCP> Reply-To: colwell@m6.UUCP (Robert Colwell) Organization: Multiflow Computer Inc., Branford, CT. 06405 Lines: 47 Keywords: RISC,array >Well, it's not really new [Seymour Cray has been designing RISCy machines >for eons, the IBM 801 is well over 10 years old, and various folks >(Pyramid, Ridge) have been selling RISC machines for a while.] The only >really recent part is doing it in VLSI, and the ramifications thereof. >There have been many discussions in this newsgroup, so rather than repeating >them, how about just a few good references: > >1) John Hennessy, "VLSI Processor Architecture", IEEE Trans on Computers, >C-33, no 12, Dec 1984, 1221-1246. > >2) David A. Paterson, "Reduced Instruction Set Computers", Comm. ACM 28, >1 (Jan 1985), 8-21. > >3) George Radin, "The 801 Minicomputer", ACM SIGARCH 10, 2 (March 1982). >-- >-john mashey DISCLAIMER: >UUCP: {ames,decwrl.prls,pyramid}!mips!mash OR mash@mips.com >DDD: 408-991-0253 or 408-720-1700, x253 >USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086 But please keep in mind that there is still room for other opinions here...I see almost nothing RISCy about Pyramid or Ridge. Pyramid seemed like a RISC to the novice because it had lots of registers organized in windows, which was like RISC-I, and RISC-I is a RISC, so Pyramid must be too? No way, unless you think the IBM 801 was not. By the way, all three of the above papers were reprinted in Stallings' recent 'Reduced Instruction Set Computers', IEEE catalog EH0251-9. I notice that nobody has taken up Wirth's challenge at the ASPLOS-II conference concerning the dangers inherent in the current approach of "performance above all else". He mentioned items like undetected integer overflows and broken floating point processing as being the norm. I bet he knows this, but he didn't mention it. The problem is that when you've got several streams of floating point operations in the air at the same time, you could have a royal mess if any one of them takes an exception AND you have to handle it a la IEEE. One way out is to have the exceptions be flagged in a sticky register, and check that register at the completion of the computations; if clean, you win. If you do the flops sequentially, you can tell the user exactly what went wrong and where, but it won't help -- you won't have any users, because they'll have bought someone else's machine. -- Bob Colwell {yale!mfci!colwell} {203-488-6090} -- (pretend there's a standard generic disclaimer here)