dkirk@k.gp.cs.cmu.edu (Dave Kirk) (05/17/89)
In article <19433@obiwan.mips.COM> mark@mips.COM (Mark G. Johnson) writes: > >(The mechanism described is that implemented in Intel's embedded- >controller RISC cpu, the 960. Note the nine.) >-- > -- Mark Johnson > MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086 > ...!decwrl!mips!mark (408) 991-0208 It's becoming less clear when a RISC stops being a RISC. Intel's 80960 has certain features which definitely make the tag of a RISC chip somewhat questionable. It's not that I think Mark's terminology is incorrect (indeed I'm sure more people agree with the RISC label), I just wonder what features have to be missing/present to consider a CPU a CISC. The 80960MC has addressing modes such as "Register Indirect with Index and Displacement, data types including integer, real, decimal, bit and byte, and the instruction set includes microcoded/interruptible/ multicycle instructions. While some of this is unique to the MC version, the 80960 still includes all of the addressing modes and multicycle instructions (shifts, multiply, divide ...) Which feature is key in establishing the 80960 as a RISC: - load/store architecture; - register windows; - "some" single cycle instructions; - manufacturer's marketing claim? Which features are key in establishing the 80960 as a CISC: - complex addressing schemes (index, displacement, indirection ...); - complex data types (floating point, decimal...); - multicycle instructions (flt pt, shifts, multiply/divide ...)? It seems difficult to decide if the 80960xx is RISC or CISC. Is it possible that the 80960 is RISC and the 80960MC is CISC? Flames to kirk@maxwell.ece.cmu.edu --
mcg@mipon2.intel.com (05/30/89)
In article <5004@pt.cs.cmu.edu> dkirk@k.gp.cs.cmu.edu (Dave Kirk) writes: >In article <19433@obiwan.mips.COM> mark@mips.COM (Mark G. Johnson) writes: >> >>(The mechanism described is that implemented in Intel's embedded- >>controller RISC cpu, the 960. Note the nine.) >>-- >> -- Mark Johnson >> MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086 >> ...!decwrl!mips!mark (408) 991-0208 > >It's becoming less clear when a RISC stops being a RISC. Intel's 80960 >has certain features which definitely make the tag of a RISC chip >somewhat questionable. It's not that I think Mark's terminology is >incorrect (indeed I'm sure more people agree with the RISC label), I >just wonder what features have to be missing/present to consider a CPU >a CISC. As has been said here in the past, a RISC processor is any processor announced after 1985 (or was it 1984). I do not wish to enter the fray regarding the definition of 'RISC' - I believe it to be an acronym that has lost any strict technical meaning it mayhave ever had. However, I do wish to address some issues raised in the remainder of the posting. >The 80960MC has addressing modes such as "Register Indirect with >Index and Displacement, data types including integer, real, decimal, >bit and byte, and the instruction set includes microcoded/interruptible/ >multicycle instructions. While some of this is unique to the MC version, >the 80960 still includes all of the addressing modes and multicycle >instructions (shifts, multiply, divide ...) The 960 architecture is defined in four levels: the Core Architecture, currently implemented by the 960KA, which includes what one would consider a "normal" set of RISC reg-reg instructions, load/store, and a set of additional instructions (explained below); the Numerics Architecture, implemented currently by the 960KB, which adds a full-function FPU including single, double, and extended-precision IEEE arithmetic, with trig functions; the Protected Architecture, implemented currently by the 960MC, which adds a full memory management unit, and a hardware implemented Ada tasking model; and the Extended Architecture, proprietary to BiiN Corporation, which adds a capability-based object-oriented memory management and protection mechanism capable of 56-bit network-distributed virtual memory. The 960 was architected to provide the basis for many different implementations, both low-cost (in the sub-$20 range), and high-performance (> 100 VAX MIPS) implementations. Because, perhaps, the 960 was designed by others than Stanford/Hennessey/MIPS/Titan RISC people or Berkeley/Patterson/SOAR/SPARC RISC people, it does differ from the "dogma" quite substantially. All the addressing modes (including the complex ones) are common to all levels of the architecture. This allows an address-generation unit independent of the normal integer unit to perform address calculations in parallel with normal calculations. The COBR (compare-and-branch) combined instructions help instruction density when the delay slot cannot be filled, call and return allow efficient access to a larger register set implemented by a stack-frame cache, as well as keep instruction density closer to VAX than, e.g. MIPS. So-called "microcoded" instructions are actually implemented by on-chip "macros" of normal 960 instructions. Since ROM cells are less than 25% the size of RAM/cache/register cells, this is a substantial efficiency for frequently- used instructions, and adds little or no complexity to the path that executes the vast majority of the so-called "RISC" instructions. >Which feature is key in establishing the 80960 as a RISC: > - load/store architecture; > - register windows; > - "some" single cycle instructions; > - manufacturer's marketing claim? Perhaps also 3-operand register-register normal instructions. The number of cycles of latency caused by an instruction is an implementation, not an architectural feature (at least on the 960, this is not true of some other RISCs) - an upcoming version of the 960 has predominantly one-cycle latency instructions. >Which features are key in establishing the 80960 as a CISC: > - complex addressing schemes (index, displacement, indirection ...); > - complex data types (floating point, decimal...); > - multicycle instructions (flt pt, shifts, multiply/divide ...)? Shifts are not multi-cycle. Multiply/divide are multi-cycle as an implementation decision, not architecturally. Floating-point is an optional on-chip function-unit, more efficiently implementing what others implement in a second chip. Yet, if these make the 960 non-RISC, so be it. We have no particular fondness for that label. >It seems difficult to decide if the 80960xx is RISC or CISC. >Is it possible that the 80960 is RISC and the 80960MC is CISC? If you think the 960MC is CISC, then you should see the capability-based MMU in the XA. Seriously, you are confusing (as many do) architecture with implementation. Don't feel bad though, most of the RISC processor designers have done the same thing. Other than cranking up the clock rate as the fab people produce better processes, the potential for flexibility and additional performance enhancement in some of these "RISC" architecures is small or non-existant. S. McGeady Intel Corp.
tim@crackle.amd.com (Tim Olson) (05/30/89)
In article <m0fRxRp-0001fDC@mipon2.intel.com> mcg@mipon2.UUCP (Steven McGeady) writes: | Perhaps also 3-operand register-register normal instructions. The number | of cycles of latency caused by an instruction is an implementation, not | an architectural feature (at least on the 960, this is not true of some | other RISCs) - an upcoming version of the 960 has predominantly one-cycle | latency instructions. This brings up an interesting question. I believe that in the 960{KA,KB,MC} part(s), the register file is 1-read, 1-write. This means that 3-operand instructions can execute in a single cycle only if one of the operands is directly forwarded from the previous ALU operation -- otherwise, it takes 2 cycles just to read the operands. Could you discuss the tradeoffs behind the decision not to support 2 read ports? What frequency of pipeline stalls are caused by having to double-cycle the register file? -- Tim Olson Advanced Micro Devices (tim@amd.com)