Seriously, it's not really possible to have a genuine "HISC" environment. Either the underlying layer is basic or it isn't. That is what's really important, not what is visible from "outside".

The RISC architecture follows the idea that you have as -few- instructions as possible, thus making it faster to search for what to do.

If you were to, say, have a whole load of RISC systems wired together, in such a way that they appear to be a CISC, in terms of the instructions available, it's -still- RISC. You just have (effectively) a Beowulf of RISCs.

On the other hand, if you have a translation layer, converting CISC instructions into RISC ones, you have a CISC architecture, because all you've done is move the search (which is the crucial difference in philosophy) from one layer to another. It's still present. (The previous case didn't have a search mechanism, because it doesn't need one. You can filter to multiple destinations without needing any kind of search.)

It's that search that makes the crucial difference between whether something is RISC or CISC. If the search is complex or lengthy, it's CISC. If it's simple -and- quick, it's RISC. There are no other cases.

Of course it's possible to have a hybrid! Look at the powerPC chip. In designing that chip, they tried to follow the risc mentality, having simple instructions and a low orthogonality. They also however wanted to have powerful math instructions, and you end up having instructions like a+b*c as a single instruction... certainly risc.

CISC/RISC is more than instructions that 'do alot', the complexity of instructions also takes these into account:

CISC characteriscs:

(Unless you have Processor-In-Memory architecture, you -HAVE- to load your data into the processor somehow!)

Multiple addressing modes - provided your instruction search time isn't impacted, these don't change whether a processor is RISC or CISC. The whole point of RISC is reducing the overheads of processing. So, if you don't add any overheads, you're not changing the type of processor.

Variable length instructions - Depends on how it's implemented. Remember, the key is the overhead. If the maximum size of instruction can be fetched in a single transaction, it's quite irrelevent as to whether you've fetched 1, 2, 4, 8 or a million bytes. It becomes CISC if you have to do multiple fetches and parse the data.

Instructions which require multiple clock cycles - you'll find even the early ARM and Transputer chips (the very ESSENCE of RISC design!) had opcodes which took more than one clock cycle. Indeed, it's impossible to do anything much inside a single clock cycle. (Even basic operations, such as adding two numbers, or fetching a word from memory, only just fit into that, and sometimes not even then. The 8086 took 2 clock cycles to do either of these.)

The problem, I believe, is the changing definition of RISC and CISC, =NOT= what chip manufacturers are doing. I use the classic definitions that I learned when RISC architectures first appeared in Britain, where (IIRC) the idea was pioneered by companies such as ARM and Inmos.

Register to memory, memory to register and register to register are all perfectly valid RISC operations. Indeed, you HAVE to have R->M and M->R if you're going to program in assembly at all!

Well, what the original poster meant was instructions like memory=register+memory which is rather CISC. RISC machines are usually load/store machines where you can only to arithmetic on operands in registers. Obviously, you can load and store registers from/into memory on a RISC chip.

Instructions which require multiple clock cycles - you'll find even the early ARM and Transputer chips (the very ESSENCE of RISC design!) had opcodes which took more than one clock cycle. Indeed, it's impossible to do anything much inside a single clock cycle. (Even basic operations, such as adding two numbers, or fetching a word from memory, only just fit into that, and sometimes not even then....)

True, a large part of the reason for RISC is to facilitate pipelining. "Traditional" RISC instructions take 3-5 clock cycles, usually all 5 even if they don't need it.

Its interesting what the article says about the G4. I hadn't thought of it before, but that velocity engine (vector unit) must have a whole lot of instructions...

Has anyone gotten their G4 yet?

"Linux - It's Bill's own Y2K problem"

You are forgetting that memory-to-memory instructions are a waste of time and bandwidth, and are totally out of favor now that CPUs are so much faster than RAM.

The question is not RISC / CISC, as even Intel says RISC (soon VLIW / EPIC), but using RISC to emulate CISC seems to be quite inefficient if a PPC at 400 MHz can keep up with a 700 MHz chip.

Jeff DeMaagd - newly declared enemy of reality.

From this point of view, the difference in the way "CISC" and "RISC" chips interact with memory is that, with a CISC chip, memory is implicitly used as a backing store for register contents while, with a RISC chip, the backing store is managed explicitly.

In practice, then, even this seemingly fundamental difference may not be that big a deal.

RISC does stand for Reduced Instruction Set Chip, but that doesn't mean less instructions, it means less Instruction Formats. Think of how many different instruction formats x86 has, with varying lengths of instructions, non-orthogonal instructions, etc, compared with the simplified instructions provided by RISC processors, which might have as few as 3 or 4 different instruction formats.

RISC really should have been SISC, for Simplified Instruction Set Chip, but that clashes with CISC, ho hum....

Remember, you don't get a RISC chip (Reduced Instruction Set Chip Chip)! :-)

The article was silly really, the author didn't look beyond the word 'Reduced' in RISC, thought it meant less instructions, then saw that most RISC chips have tonnes more instructions than most CISC chips, and arrived at the wrong conclusion. Hell, a simple ARM chip has a theoretical 4 billion instructions (all conditional etc) but there are much fewer general operations.

RISC:

• Register-Register operations (e.g., add)
• Load-Store operation (Mem to Reg LDR, STR)
• Simplified Instructions, less Instruction Formats
• Orthogonal Architecture (i.e., add can use any General Purpose Register)
• Pipelined Architecture from the beginning
• and many many more, read comp.arch FAQ for more details

CISC:

• Variable Length Instructions (e.g., POLY in VAX)
• Non-orthogonal, i.e., must use register BX for multiply instruction result
• Many addressing modes... nice when there were no such things like caches and memory was as fast as the processor
• Good when not many transistors
• etc

CISC chips now typically have a RISC core, where instructions such as ADD (contents of memory A), (contents of memory B), (resulting memory location) are broken up into micro-ops, LD A, LD B, ADD A,B,C, ST C

Anyway, just my (small) point of view...

No.

With Instruction Set Architectures (ISA) I believe that orthogonal means that an instruction such as add can use any register (in a general purpose register file) as its arguments, whereas with a non-orthogonal architecture, you can't, so you end up with instructions where you have to use certain registers in order to execute a certain instruction, which is hell for compilers!

I forgot to add that RISC was developed because of compilers, and that only the common compiler instructions were implemented, because compilers are too stupid to work out that you could use a certain instruction to implement a certain function. Compilers on CISC tended to only use certain instructions and not others, making those other instructions worthless! Of course, thesedays you would have hand-coded HALs which are written in assembler and can use the complex instructions (such as 3D-Now! and SSE) and these fuctions are called by programs...

Ah! The end of the working day is nigh! Time to go and assemble my new semi-computer (gutting ye olde computer for some stuff)

I remember learning a bit about this in class.

The point was made that it used to be neccesary to hand optimise code on CISC chips, but on RISC chips it has been to complex for quite a long time, and most modern compilers are better at it than humans, and the optimising by the compiler was done very differently (now that is a technical term - I can't remember the details) on RISC chips compared to CISC.

I'm always annoyed by some commercial Windows compiler makers who take a long time to add instructions for the new instruction sets in MMX etc chips. I would imagine that these hybrid chips would be even worse - having to add stuff to a RISC targeted compiler might take even longer.

Of course, I may be way off track here - I slept though most of Uni.

Corrections are of course welcome. *S*

That way you'd understand that the article's purpose is not to debunk RISC, but to point out that the distiction today is almost meaningless in the framework of the old RISC v CISC debate.

The author's "main evidence" as you call it, is merely laying out the main question of the article, ie is there a difference nowadays? As you read on, there are numerous examples cited of the blurring distinction, eg G4's with the Velocity Engine (162 _extra_ instructions), and the Pentium II, a classic CISC CPU, with its internal microcode (RISC) architecture.

Cheers,
Justin.
Don't sweat the petty things and don't pet the sweaty things

I'd have to agree that some sort of explict-parallelism approach such as VLIW is the way to go. Compatibility with future parts at the object code level is difficult, but the gains at a particular process node are worth it. I'd rather spend my transistors on functional units than on hardware scheduling engines, since those are expensive. In contrast, I don't have to ship the compiler with every chip. And even if I did, it's software, which is much, much easier to manipulate.

I say this as someone who codes for a VLIW during my day job. :-)

When the first RISC machines came out, superscalar execution hadn't been invented yet.

Some processors (Cray for one) had been doing this years before RISC came out. RISC actually makes superscalar execution easier because there is more consistency in the instructions and they don't hit as many functional units in a single instruction.

The fast CISC chips (PII, Athlon) do instruction conversion into RISC, under the bonnet, for this and many other reasons. So if the debate is over, its because RISC won -- big time.

I also think that the ideas behind RISC such as "move the complexity from the chip into the compiler" also apply today and that VLIW is an example of this applied to scheduling and the branch hints on the Alpha is another example of this applied to branching.

There is also promising work done on MISC (Minimal Intruction Set) with simple chips doing lots of instructions per second.

That was a very disappointing article.

The rule in computer architecture seems to be that everything was done back in the '60's and IBM holds all the patents. :)

None of the stuff discussed in the artical was particularly revolutionary at the time of RISC I. Bringing it all together on a microprocessor was the missing element.

--
Some little people have music in them, but Fats, he was all music, and you know how big he was. -- James P. Johnson

You are not wrong. The 6600 was Cray's baby, the machine he always dreamed of making. The 6600 came out in 1964 (?) and I believe Cray was still there through the early 70's.

Of course, if you look at the instruction set for the CDC 6000 series you recognize that Cray anticipated RISC by a number of years. This observation seems to upset some people for some reason.

-Jordan Henderson

When the first RISC machines came out, superscalar execution hadn't been invented yet.

Some processors (Cray for one) had been doing this years before RISC came out.

I also think that the ideas behind RISC such as "move the complexity from the chip into the compiler" also apply today and that VLIW is an example of this applied to scheduling

The fast CISC chips (PII, Athlon) do instruction conversion into RISC...so if the debate is over, its because RISC won -- big time.

One point that needs to be made lest history is re-written though:

And as for your "debate"--of course RISC won big time. It came out nearly 10 years after the first chips made with the "CISC" philosophy. As was, IMO, rather compellingly and insightfully explained in the article, "CISC" chips were the best possible solution to the awful state of complilers and memory available at the time.

When RISC came out it wasn't seen as a simple logical progression. I even heard it refered to as a fad that would disappear when transistor counts improved. There were tons of arguments for keeping CISC (it does more work per instruction, RISC processors were only faster because they had more registers, the early Sparcs couldn't do multiplication to save their lives ...) and I remember being called an idiot by an Intel engineer for saying that CISC was not going to last. Digital engineers were also very vocal in damning CISC when the Alpha came out. This was because so many people were defending CISC.

I also think that the attitude that RISC is just an ISA (as seen in a lot of replies) is a software persons argument. The thing doing the work in PIIs and Athlons is running simple instructions and is RISC whether it is doing the can-can or emulating x86 as far as the outside world is concerned. That is why some hardware and marketing people think of them as RISC.

Sorry for the disappointing comment.

That's what I always thought.

What I learned from my last computer design course, was that RISC implemented all instructions in hardware. While CISC implemented all instructions in microcode.

"Evil will always triumph over good, because good is dumb." - Dark Helmet (Spaceballs)

RISC vs. CISC
RISC vs. CISC II: Hellazon fires back
RISC v. CISC III: The last word?

I think most people have realized that RISC CPUs (in the sense of the early MIPS and SPARC designs) have not been made for a long time. Nowadays, the only real remaining differentiator between a "RISC" machine and a "CISC" machine is whether the instruction set is LOAD/STORE based or has memory operands on various instructions. There are several reasons for this:

• Perhaps the largest reason: Backwards compatibility. If you look at the MIPS and SPARC architectures, they both brought to the table the concept of "delay slots". For instance, a LOAD instruction on MIPS won't write its result until after the second cycle, since the LOAD is pipelined over multiple cycles. (SPARC's delayed branches are similar.) Change the pipeline depth, and you sign yourself up for alot of hocus-pocus to continue playing this charade.

• The relative cost of operations changes pretty radically over time. For example, when RISC debuted, ideas such as including a multiplier on-chip were out of the question, since they cost too many transistors. So instead, programs implemented multiplies with shifts and adds, or in some cases, with lookup-tables. Nowadays, multipliers are relatively cheap when you consider how much the transistor budget has grown.

• Memory latency has gotten really bad relative to CPU performance. This is one of the largest drivers of out-of-order issue, actually. IBM invented this way-back-when before caches were feasible. (It escapes me on which machine they did this, but it was one of the old mainframes.) The idea is that you can cope with latency by allowing instructions to run when their data arrived -- whether it's from a slow memory or slow floating point unit. (Those of you with Hennesey & Patterson on your shelf: Go look up the Tomasulo scheduling algorithm.)

• The cost of communication and control has gone way up as pipelines have gotten deeper and transistors have gotten faster than the wires that connect them. "Complex" instructions which reduce communication, and sophisticated branch-prediction schemes which try to flatten control are attempts to address these issues.

The point is that these are difficult problems, no matter what type of architecture you have. Even Alpha spends alot of transistors allowing such things as "hit under miss" in the cache (allowing one stream of instructions to proceed while another is stalled waiting for a cache service).

Every so often, when the gap between the original "programmer's model of the architecture" and "what we can do easily in silicon" gets too wide, it becomes necessary to move to a new paradigm. With this shift comes a new programmer's model. Moving from "CISC" to "RISC" was one such paradigm shift. One could argue that we're due for another one, and that VLIW/EPIC-like schemes are the new contenders.

Some approaches, such as traditional VLIW, say "We're not going to worry so much about bout presenting a traditional scalar model to the programmer. We're going to expose our complexity to the compiler and let it do its best, rather than play tricks behind its back." These work by exposing the functional units of the machine, removing alot of the control complexity. These are today's "direct execution" architectures. (See TI's C6000 DSP family for a live example of VLIW in the field.)

Intel's EPIC takes VLIW a step further. It adopts alot of the explicitness of VLIW, but it retains alot of the chip complexity that's required to retain compatibility across widely varying family members. It's too early to know how this will turn out, but I'm somewhat concerned that it does not reduce complexity.

All-in-all, it'll be interesting to see how this turns out. Who knows what type of architectures we'll be programming in 20 years...

The author of the article rightly notes that a basic design philosophy difference is where the burden of reducing run-time should be placed. The original RISC philosophy was to place the burden on software--this is especially true of (V)LIW processors--whether the programmer, the compiler, or the set of libraries. CISC (or more rightly "old style") design philosophy sought to place the burden on the hardware. Effectively microcoded CISC is like RISC with a fixed set of library functions in a specialized read-only high-speed cache. (The obvious limitation of this being that the library is fixed in hardware.)

Separating load/store into a specialized (memory) instruction nearly forces fixed instruction size (the real mark of RISC). Yet this also works with the general idea of modularized (and potentially superscalar) processing--of course, the same could apply to microcode. Fixed instruction size has a consequence for memory access. A CISC (variable length) instruction fetch would either have to load a maximum-instruction-size number of bytes or use multiple fetches for longer instructions. (One could reduce the performance loss of this if the first load included the opcode and later loads would contain (optional) register ids or immediates (hard-coded values). Since the register ids might not be needed until a second or third stage of the pipeline, the load delay would be invisible--the next instruction fetch would forward the values to the appropriate place in the pipeline. This would make some instructions very fast with a low memory bandwidth--the number of additional values needed might vary from 0 to 3 ("save state," e.g., might require no arguments, while increment might require one argument.))

The RISC vs. CISC debate also concentrates on general purpose processors. In a single, purpose processor (with a stable, well-defined operation set), a direct-execution CISC design would make sense because the "library" of code is so small that hardwiring it (not merely placing it in ROM for a microcode implementation, though such would also be more efficient that a RISC design, it seems) would increase speed. This, of course, assumes that the design costs are low enough to justify making a specialized design for a specialized function. (With improved design tools and efficient low-output manufacturing, this could become more common. Of course, some are looking to processors that dynamically change their wiring to allow changes of specialization without replacing the hardware.) Certain classes of Digital Signal Processors would seem to fit into this category. 2D and 3D video accelerators--which rely on a generalized processor for certain functions--might be another reasonable CISC application (well defined problem, very limited instruction set required, relatively stable algorithms).

A true post-RISC processor (for general purpose computing) would take advantage of hardware scheduling (which allows scheduling based on the current data--something even a compiler cannot do), compiler optimization (which would probably include (V)LIW probably with some predication information), and programmer knowledge (a high level language and set of libraries that allows the programmer to share knowledge of the design with the compiler). IA-64 seems to place too little burden on the programmer (perhaps rightly based on the lack of time put into writing code well--by open-sourcers who often just want to make a working program (not considering performance, cooperative development, system integration, etc.) and by 'commercial' programmers who are often trapped by unrealistic deadlines (it is faster in the short term to implement a kludge than to design (write) or research (find another's implementation) good code)) and excessive burden on the compiler (this MIGHT be reasonable since Intel can control the compiler--that being a single unit of coding). IBM's Power-4 seems to emphasizing programmer cleverness (multithreading, multiprocessing, tight libraries) and to a lesser extent compiler cleverness.

What I wonder is why no system seems to support vector-processor-style non-unit stride in the cache (This could perhaps be implemented by having a vector mode which took, say, one set of a 2-way set associative cache and used it for non-unit offset entries. Say every N cache lines might be associated with an address, offset, and length. This would make certain vector processor functions work very well in general purpose processors.), why a sticky bit is not provided for cache (This would allow code fragments that are known to be reused somewhat frequently but would otherwise be removed by other loads.), why memory is not segmented into non-virtual-addressed kernel, non-virtual-addressed common library, and virtual-addressed application space (This would seem to allow some of the benefits of embedded systems without losing the benefits of virtual addressing where it makes sense. The compiler would use a table of system-call locations and common-library-function locations so that at linking, the jumps would be to these absolute locations. Of course, changing the libraries or kernel would require relinking all applications, but this might be relatively quick and the frequency of having to do such could be reduced by placing libraries like libc (commonly used, very stable implementation) at the beginning of the memory space and using small functions or even empty space to pad larger functions. Placing the kernel memory space onto a processor daughter card would also reduce the card-board memory traffic. Using separate kernel caching might also reduce application cache misses after a kernel invokation. The memory access style of kernels might also be used to design that specific memory system--the kernel (and the common libraries) are not paged out to disk, so the instruction memory could be designed for very slow write and fast read. (Whether the improved performance would justify the cost of a specialized memory system is questionable.)

While that is an oversimplification, it looks an awful lot like truth, sometimes. For years, processor manufacturers have touted their new "RISC" processors even though those "reduced" instruction sets might have more instructions than the 8086.

Of course, the real hallmarks of a RISC processors are the load-store architecture, the large general-purpose register sets, and the uniform instruction size, but even those aren't sufficient to give a significant performance advantage to a computer based upon the RISC architecture. In fact, various benchmarks provide evidence that CISC vs RISC has very little effect on the performance of the computer.

So, where did the RISC vs CISC distinction come from, and why do RISC processors have a reputation of being faster, all other things being equal, than CISC processors? The answer has to do with what is now the prehistory of microcomputing. Back in the dim dawn of history (early 70's) microprocessors were for embedded systems. They were, therefore, designed to minimize part count and that meant optimizing the program space. The early embedded systems were programmed universally in assembly language and programmers typically used various tricks to use space very efficiently because space was more at a premium than time.

The complexity of those early embedded systems processors was mostly focused on reducing instruction count and instruction size as much as possible. "Bit mining" while it is still around today, was a way of life for the early microprocessor programmers, and the processor manufacturers built processors to facilitate that effort.

However, in the middle of the 70's, some people started putting these processors into general-purpose computers, and the microcomputer market became significant. That drew the attention of some processor designers who wanted to add some of the advanced performance-enhancing features, like caching and pipelining, from minicomputers and mainframes, to the micros.

The only problem was that the largest scale of integration available in the 70's was a few thousand transistors. When you've got 4000 transistors in your whole processor, you're going to need to trim unnecessary functionality away from the whole processor if you want to add an on-processor cache that's of some use to somebody. Hence the desire for a reduced instruction set.

Originally, the idea was to take those transistors that would otherwise go into complex instructions and put them into performance-enhancing features. The loss of memory efficiency was not a problem because they were intended to be put into fairly large, fairly capable, and fairly expensive computers.

Of course, now the processor designers have silicon budgets of millions of transistors, and the amount taken up by the instruction set is relatively tiny. That means that, in the 20 or so years since RISC processors were first envisioned, the instruction sets of the so-called RISC processors have gotten far more complex and the CISC processors have gotten essentially all of the performance-enhancing features of the RISC processors such that there is no real difference between them any more. Moore's law has made the distinction obsolete.