Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!purdue!decwrl!ucbvax!agate!helios.ee.lbl.gov!lll-tis!lll-winken!uunet!portal!cup.portal.com!bcase From: bcase@cup.portal.com (Brian bcase Case) Newsgroups: comp.arch Subject: Re: CISCy RISC? RISCy CISC? Message-ID: <10358@cup.portal.com> Date: 22 Oct 88 19:57:10 GMT References: <973@naucse.UUCP> <10192@cup.portal.com> <1293@edge.UUCP> Organization: The Portal System (TM) Lines: 64 >we became Edgcore Technology, Inc. Trumpets playing... A few of us at Apple wanted to get one of your boxes to run Macintosh: we wanted to see just how it would feel to use a Mac at that speed. We conjectured that scrolling would be too fast to tolerate! "Wait! there goes my text! Stop!" >ME>Even so, there are no new CISC designs >ME>being done, that I know of. >I presume that this means "instruction set designs", not computer designs. >There have been a ton of new systems using old instruction sets recently; >for example Amdahl just came out with a stupendous box using the 370 set. Yes, I did mean to say new CISC instruction set designs. Sigh, I have to be more careful. >As for designing new instruction sets, the fact that CISC has attained a >level of stability while new RISC instruction sets seem to appear each month >is hardly a point in favor of RISC. New instruction sets usually appear >because there are perceived major flaws in the existing sets. You are right, sometimes new things come out because old things are inherently flawed, but sometimes new things come out because we have thought of better ways! This doesn't necessarily describe the activity in the RISC arena, but it will in the future. Thus, I perceive the introduction of new RISC instruction sets as an advantage! It does at least one important thing: it makes you realize that you shouldn't rely on one instuction set if you hope to be able to take advantage of the state of the art in price/performance. Sure, you can have 30 MIPS 370s, if you are willing to pay $10 Mega. Me? I'll stick with something a little closer to the cost of a car. :-) Counting on the instruction set being the same 3 years from now seems like a limiting thing to me. Surely (*stop* calling me Shirley) we can think of something better than RISC (Multiflow is an example). Notice that this is where the MIIL concept comes back in. I dissagree with the comment someone else made claiming that the issue of MIILs is a read herring. We need something other than source to insulate programs from architecture tweaks. >As we at Edgcore have shown, it is both possible and practical to implement >CISC instruction sets at speeds faster than RISC. But -- it doesn't all fit >on one chip. Yet. I would bet, a fair amount, that by the time you have one processor on a chip, there will be single-chip RISC multiprocessors; maybe not for sale at Fry's, but somewhere. I don't know how the bandwidth requirements will be satisfied, but they will exist. >In a mainframe design, who cares if it fits on one chip? Jeez, in our E2000 >system we need an entire triple-high VME card jam-packed with surface-mount >parts just to hold the *caches* that we need to have to keep from starving >the CPU. The complexity and board area of the CPU itself is insignificant >compared to that required by mainframe-sized multi-level memory systems. yes, everyone has the same problem: the memory hierarchy. >Nobody's going to be building a "single board mainframe" with today's DRAM >and SRAM technologies. If/when those RAM technologies do reach that point, >it's likely that our 1-instruction-per-clock-cycle 680x0 will fit on one chip >too. Of course, by then there'll be a different definition of "mainframe"... Yes, it depends on the definition of mainframe. It could be argued that, for some types of computations (dhrystones? :-), single-board computers exist that are faster than mainframes.