Path: utzoo!mnetor!uunet!steinmetz!davidsen From: davidsen@steinmetz.steinmetz.ge.com (William E. Davidsen Jr) Newsgroups: comp.arch Subject: Re: Yield of core-MIPS chips [MIPSCo yield? && Other Issues] Message-ID: <10170@steinmetz.steinmetz.ge.com> Date: 30 Mar 88 12:32:18 GMT References: <2904@omepd> <751@esunix.UUCP> <2089@ho95e.ATT.COM> Reply-To: davidsen@crdos1.UUCP (bill davidsen) Organization: General Electric CRD, Schenectady, NY Lines: 29 In article <2089@ho95e.ATT.COM> wcs@ho95e.UUCP (46323-Bill.Stewart.,2G218,x0705,) writes: | You've got it backwards - the theory of CISC is that you really need | binary-coded-decimal-graphics-interpreters because your COBOL programs | draw a lot of pie charts, and need them in hardware to go fast. | RISC says make the hardware do the few simple things *everybody* needs, | and do them elegantly and real fast. That way it's easy to write | good compilers, and fast enough to do your custom work in software. Actually a CISC processor is in reality two parts: a RISC processor which executes a simple native language, and a silicon compiler which takes a pseudo assembler (what we see as the native instruction set) and translates to the native RISC instructions (microcode). Seriously, when I see people claim that they are taking a pseudocode generated by and doing a translate and optimize so they can run it on RISC, I wonder why all the fuss? In a few more years, perhaps ten, we will know how to build a translator in silicon which does a better and faster job of translation, NOP fills, etc, than we are now doing in software. I think we will still do a better job with software at that time, but it may not be cost effective. IBM sort of used this approach with the PC/370, modifying a 68000 to translate 370 opcodes into the same microcode that the 68000 conventional opcodes use. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me