CISC Processors

(Complex Instruction Set Computing)

This class of microprocessors have characteristics that fit most early
microprocessor designs.  As such their characteristics consisted of practical
design choices for the time that they were invented (around the 1970's). 
For some applications,  the rate at which data can be fetched from memory
is a limiting factor to the performance of the application.  These types of
applications are still well suited to the design guide lines of CISC
processors.  Two common design choices that reduce High Memory
Overhead are:

 Variable Length Instructions

 Extensive Instruction Set

Another common attribute to CISC processors is support for some

programming sequences that:

 Hinder a processor's performance

 Occur rarely
 Could have been initialy defined as producing unpredictable results

Frequently this support occur because we didn't know the preformance

implications the sequence would have on future design choices.  One of the
significant examples of this is support for Self Modifying Code.
High Memory Overhead
The programmers who made the CISC processor were going for one goal;  to
conserve memory as best they could.  Back when CISC processors were first
made, memory was very expensive.  This made them compact everything
instruction to as small as they could get it so to save memory.  Some common
mechinisms, used by CISC processsor designers, to reduce memory usage are:

Variable Lenth Instructions

Variable length instructions were used in CISC processors to limit the amount of
memory each instruction took up.  It also made it so that any instruction length
would fit in one cycle so it wouldn't have to make two cycles to get one piece of
data.  Saving memory is not a bad idea, but one down side to this design guide
line is it is difficult for the I-unit to preform out of order execution, which slows
the computer down greatly.  Another down side is it is very difficult to find the
opcodes in the upcomming instructions.  Both RISC and EPIC processors use fixed
length instructions because it is easier to see whats comming up.

Extensive Instructions Set

Frequently CISC supports SS (Storage to Storage) instructions.  A SS instruction is
the act of allowing data to be moved from one place in memory to another in
one instruction.  The good thing about SS instructions is CISC processors only
have to use one instruction to preform what would take a RISC processor two
instructions to do; one to load the data from memory into a register and another
to store it in memory again at the new destination..
Self Modifying Code
Self modifying code was a great idea, back in the days when a fair amount
of assembler code was written. Self modifying code is a process in which
an upcoming instruction is modified before it is reached. When CPU's were
not pipelined, it was easy to determine whether the instruction was reached
yet or not.  Basically, only the current instruction was being executed, so all
future instructions had not been reached yet. With this design guideline,
programmers can do some pretty tricky things. In a lot of code, the opcode
of a branch instruction is changed to that of a nop (no operation)
instruction. This allows, at runtime, for a branch always (jump) or even a
branch conditional to effectively be changed into a branch never. This is
useful for determining at runtime what portions of a program are to be
executed and then the branches are changed as needed so only those
portions are executed.
The down side to self modifying code is there aren't any current high-level
programming languages that allow you to create self modifying code
(except maybe C but it would be rough). It is still used today, but mostly
only to patch parts of a program. Many CISC chips were designed before it
was known how much more difficult pipelining support is on processors
that completely support self modifying code. Most RISC processor designs
place limitations on how self modifying code sequences are performed. For
instance, they typically require that the instruction being modified must be
at least some number of instructions away from the instruction that causes
the modification. Normally the number of instruction is specified to be one
more than the number of stages in the processors pipeline. In this manner
the processor does not have to worry about an instruction being modified
that is already in the pipeline. Most CISC processors did not require this
limitation during there initial release. They therefore must still support this
operation, even though it significantly complicates the circuitry needed to
support pipelining.