Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!polyslo!cindy!csusac!unify!jde From: jde@unify.UUCP (Jeff Evarts) Newsgroups: comp.arch Subject: Re: ERISC??? Summary: Cor-rect! Message-ID: <1192@unify.UUCP> Date: 25 Oct 89 17:44:26 GMT References: <16190@vail.ICO.ISC.COM> <2393@gmu90x.UUCP> <1087@m3.mfci.UUCP> <1228@crdos1.crd.ge.COM> Reply-To: jde@unify.UUCP (Jeff Evarts) Organization: Unify Corporation, Sacramento, CA, USA Lines: 27 In article <1228@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: > > IMHO too many people are concentrating on the number of opcodes rather >than the performance on real problems. Let's remember that RISC was >originally a solution to a performance goal, not some "natural >principle" which could be defended even if it had hurt performance. YES! YES! YES! >-- >bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) >"The world is filled with fools. They blindly follow their so-called >'reason' in the face of the church and common sense. Any fool can see >that the world is flat!" - anon This is important. I head somebody shuddering a few months ago about the possibility of autoincrement/decrement on a RISC chip. Done properly, this could add a big 0 cycles to each instruction, and could be a big win. Unfortunately, anyone appearing on our doorstep today with a chip like that will be branded a CISC manufacturer adding too many "features" in silicon rather than in software. Keep in mind what the object was- improved performance, not philosophy and holy wars. Just another unsolicited opinion... -Jeff Evarts #include