Differences : RISC Vs CISC
• RISC has fewer instructions // CISC has more instructions
• RISC has many registers // CISC has few registers
• RISCs instructions are simpler // CISC’s instructions are more complex
• RISC has a few instruction formats // CISC has many instruction formats
• RISC usually uses single-cycle instructions // CISC uses multi-cycle instructions
• RISC uses fixed-length instructions // CISC uses variable-length instructions
• RISC has better pipelineability // CISC has poorer pipelineability
• RISC requires less complex circuits // CISC requires more complex circuits
• RISC has fewer addressing modes // CISC has more addressing modes
• RISC makes more use of RAM // CISC makes more use of cache/less use of RAM
• RISC has a hard-wired control unit // CISC has a programmable control unit
• RISC only uses load and store instructions to address memory // CISC has many types of instructions to address memory
• RISC emphasizes on software // CISC emphasizes on hardware
Hard wired CU means CU is designed as logic circuits to handle instructions whereas Programmable CU means CU has a ROM inside it for microprogramming to handle instructions ..
Advantages of CISC
- Compiler has to do little work during translation
- Because the code is short , little RAM is required to store instructions
Using the same points above You can figure out the disadvantages of RISC by negating the points
Disadvantages of CISC
- High implementation cost
- Programs run more slowly due to complicated instructions
Using the same points above You can figure out the advantages of RISC by negating the points
Pipeline Problems
( whole text is taken from cs.stanford.edu/people/eroberts/courses/soco/projects/risc/pipelining/index.html U just need to read it briefly and understand some problems related to pipelining. Questions related to dependency issues have been asked in CAIE exams. So u need to be aware of these problems. )
A data dependency occurs when an instruction depends on the results of a previous instruction. A particular instruction might need data in a register which has not yet been stored since that is the job of a preceeding instruction which has not yet reached that step in the pipeline.
For example:
add $r3, $r2, $r1
add $r5, $r4, $r3
more instructions that are independent of the first two
In this example, the first instruction tells the processor to add the contents of registers r1 and r2 and store the result in register r3. The second instructs it to add r3 and r4 and store the sum in r5. We place this set of instructions in a pipeline. When the second instruction is in the second stage, the processor will be attempting to read r3 and r4 from the registers. Remember, though, that the first instruction is just one step ahead of the second, so the contents of r1 and r2 are being added, but the result has not yet been written into register r3. The second instruction therefore cannot read from the register r3 because it hasn't been written yet and must wait until the data it needs is stored. Consequently, the pipeline is stalled and a number of empty instructions (known as bubbles go into the pipeline. Data dependency affects long pipelines more than shorter ones since it takes a longer period of time for an instruction to reach the final register-writing stage of a long pipeline.
MIPS' solution to this problem is code reordering. If, as in the example above, the following instructions have nothing to do with the first two, the code could be rearranged so that those instructions are executed in between the two dependent instructions and the pipeline could flow efficiently. The task of code reordering is generally left to the compiler, which recognizes data dependencies and attempts to minimize performance stalls.
Branch instructions are those that tell the processor to make a decision about what the next instruction to be executed should be based on the results of another instruction. Branch instructions can be troublesome in a pipeline if a branch is conditional on the results of an instruction which has not yet finished its path through the pipeline.
For example:
Loop :
add $r3, $r2, $r1
sub $r6, $r5, $r4
beq $r3, $r6, Loop
The example above instructs the processor to add r1 and r2 and put the result in r3, then subtract r4 from r5, storing the difference in r6. In the third instruction, beq stands for branch if equal. If the contents of r3 and r6 are equal, the processor should execute the instruction labeled "Loop." Otherwise, it should continue to the next instruction. In this example, the processor cannot make a decision about which branch to take because neither the value of r3 or r6 have been written into the registers yet.
The processor could stall, but a more sophisticated method of dealing with branch instructions is branch prediction. The processor makes a guess about which path to take - if the guess is wrong, anything written into the registers must be cleared, and the pipeline must be started again with the correct instruction. Some methods of branch prediction depend on stereotypical behavior. Branches pointing backward are taken about 90% of the time since backward-pointing branches are often found at the bottom of loops. On the other hand, branches pointing forward, are only taken approximately 50% of the time. Thus, it would be logical for processors to always follow the branch when it points backward, but not when it points forward. Other methods of branch prediction are less static: processors that use dynamic prediction keep a history for each branch and uses it to predict future branches. These processors are correct in their predictions 90% of the time.
Still other processors forgo the entire branch prediction ordeal. The RISC System/6000 fetches and starts decoding instructions from both sides of the branch. When it determines which branch should be followed, it then sends the correct instructions down the pipeline to be executed.
