Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!pdn!rnms1!alan From: alan@rnms1.uucp (0000-Alan Lovejoy(0000)) Newsgroups: comp.arch Subject: Re: RISC as a "technology window"? Message-ID: <5798@pdn.nm.paradyne.com> Date: 24 Mar 89 18:09:35 GMT References: <1552@vicom.COM> <15690@cup.portal.com> <1562@vicom.COM> <15702@clover.ICO.ISC.COM> <27681@apple.Apple.COM> <15695@winchester.mips.COM> <22974@ames.arc.nasa.gov> <13404@steinmetz.ge.com> Sender: news@pdn.nm.paradyne.com Reply-To: alan@rnms1.UUCP (0000-Alan Lovejoy) Organization: AT&T Paradyne, Largo, Florida Lines: 59 In article <13404@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > If [a processor] executes [high semantic content] instruction[s] in one >cycle and doesn't use microcode, I would find it hard to argue that it >is not RISC. Processors like the N10 are approaching 1 op/cycle, and the >i80486 is rumored to have an average of < 2 for non-F.P. operations. The issue here seems to be whether RISC is defined by the physical characteristics of a CPU implementation (microcode, cycles per instruction, cacheing, pipelining, number of instructions, instruction lengths...) or by the logical characteristics of an architecture (number of registers, addressing modes, instruction semantics...). The general consensus seems to be that the primary determinant is the physical implementation, but that the logical architecture heavily influences to what extent RISCy implementation techniques can be used. Except that RISC is not just a set of implementation techniques, but a design methodology and philosophy: objectively determine what the cost/benefit ratio of each proposed feature or mechanism is, and use this ratio as the priority for deciding what to put in the architecture or in the implementation. > If the processor becomes so fast that it requires memory >bandwidth which is unachievable or unaffordable[,] then the true speed of >the processor is reduced by the wait states introduced. > There will continue to be a demand for processors with a very high >instruction rate (call them RISC if you will), and also for processors >which will perform a given task faster with limited memory bandwidth. >Vendors will continue to pick the complexity which they feel provides >the greatest cost effectiveness for the entire product based on the CPU. >Cycles per operation will come down for all vendors, because they have >the techniques to use that approach. Single-cycle instructions are not just a function of how much hardware, or how many parallel functional units, you can put on a chip. Instructions whose semantics require off-chip data accesses cannot be completed until the off-chip data is fetched, no matter how many transistors you put on the chip. What should the CPU be doing while it waits for the off-chip data? With a Harvard architecture, data and instruction fetching are independent, so the fact that you fetched one instruction to do the work of three doesn't help your off-chip data-access bandwidth at all. The biggest performance bottleneck is in data fetching, not instruction fetching. Instruction-fetching bottlenecks that do exist are much more easily addressed by caches and pipelines than data-fetching bottlenecks are. The other issue is the granularity of instruction semantics. The greater the granularity, the more opportunities there are for code optimization. It also increases the generality of the instruction set, making it more likely that all instructions will be used by (and useful to) more applications. The greater the difference in semantic level (primitiveness) between the machine instructions and high-level language statements, the easier it is to have high-quality code generation for a wide variety of languages. Alan Lovejoy; alan@pdn; 813-530-2211; AT&T Paradyne: 8550 Ulmerton, Largo, FL. Disclaimer: I do not speak for AT&T Paradyne. They do not speak for me. __American Investment Deficiency Syndrome => No resistance to foreign invasion. Motto: If nanomachines will be able to reconstruct you, YOU AREN'T DEAD YET.