Path: utzoo!mnetor!uunet!husc6!bbn!rochester!cornell!batcomputer!itsgw!imagine!pawl14.pawl.rpi.edu!jesup From: jesup@pawl14.pawl.rpi.edu (Randell E. Jesup) Newsgroups: comp.arch Subject: Re: Yield of core-MIPS chips [MIPSCo yield? && Other Issues] Message-ID: <596@imagine.PAWL.RPI.EDU> Date: 31 Mar 88 02:53:12 GMT References: <2904@omepd> <751@esunix.UUCP> <2089@ho95e.ATT.COM> <10170@steinmetz.steinmetz.ge.com> Sender: news@imagine.PAWL.RPI.EDU Reply-To: beowulf!lunge!jesup@steinmetz.UUCP Organization: RPI Public Access Workstation Lab - Troy, NY Lines: 49 In article <10170@steinmetz.steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >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). Well, I wouldn't put it that way. More like a silicon interpreter than a compiler (it takes a higher-level language one instruction at a time, interprets what it means, does it, repeat. A compiler would read it it, then write out the microcode version of it for later execution. >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. CISC vs RISC is all a matter of where the balance lies. Neither is 'better', each is better for specific cases. The balance lies in the application it's designed for, the process used for the chip, the speed and size and layout of external memory, cost considerations, etc, etc. In ten years we will have smarter and better CISCs, and faster RISCs. The balance will shift back and forth, but I doubt either will be eliminated. >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. Actually, I'd thought they re-microcoded the 68000's to understand 370 code instead of 68000 code (running a different internal interpreter program, effectively.) No translation is done. I think one of the reasons RISC became popular is that on-chip references (of microcode) are no longer immensely faster than off-chip, due to things like pipelining, and chip tech allows denser, faster chips and rams. On another point: Does anyone at Mips want to comment on the R-3000? (Announced a few days ago, I believe) // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup (-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)