Community hub
Recent from talks
Knowledge base stats:
Talk channels stats:
Members stats:
Complex instruction set computer
A complex instruction set computer (CISC /ˈsɪsk/) is a computer architecture in which single instructions can execute several low-level operations (such as a load from memory, an arithmetic operation, and a memory store) or are capable of multi-step operations or addressing modes within single instructions.[citation needed] The term was retroactively coined in contrast to reduced instruction set computer (RISC) and has therefore become something of an umbrella term for everything that is not RISC,[citation needed] where the typical differentiating characteristic[dubious – discuss] is that most RISC designs use uniform instruction length for almost all instructions, and employ strictly separate load and store instructions.
Examples of CISC architectures include complex mainframe computers to simplistic microcontrollers where memory load and store operations are not separated from arithmetic instructions.[citation needed] Specific instruction set architectures that have been retroactively labeled CISC are System/360 through z/Architecture, the PDP-11 and VAX architectures, and many others. Well known microprocessors and microcontrollers that have also been labeled CISC in many academic publications[citation needed] include the Motorola 6800, 6809 and 68000 families; the Intel 8080, iAPX 432, x86 and 8051 families; the Zilog Z80, Z8 and Z8000 families; the National Semiconductor NS320xx family; the MOS Technology 6502 family; and others.
Some designs have been regarded as borderline cases by some writers.[who?] For instance, the Microchip Technology PIC has been labeled RISC in some circles and CISC in others.
Before the RISC philosophy became prominent, many computer architects tried to bridge the so-called semantic gap, i.e., to design instruction sets that directly support high-level programming constructs such as procedure calls, loop control, and complex addressing modes, allowing data structure and array accesses to be combined into single instructions. Instructions are also typically highly encoded in order to further enhance the code density. The compact nature of such instruction sets results in smaller program sizes and fewer main memory accesses (which were often slow), which at the time (early 1960s and onwards) resulted in a tremendous saving on the cost of computer memory and disc storage, as well as faster execution. It also meant good programming productivity even in assembly language, as high level languages such as Fortran or Algol were not always available or appropriate. Indeed, microprocessors in this category are sometimes still programmed in assembly language for certain types of critical applications.[citation needed]
In the 1970s, analysis of high-level languages indicated compilers produced some complex corresponding machine language. It was determined that new instructions could improve performance. Some instructions were added that were never intended to be used in assembly language but fit well with compiled high-level languages. Compilers were updated to take advantage of these instructions. The benefits of semantically rich instructions with compact encodings can be seen in modern processors as well, particularly in the high-performance segment where caches are a central component (as opposed to most embedded systems). This is because these fast, but complex and expensive, memories are inherently limited in size, making compact code beneficial. Of course, the fundamental reason they are needed is that main memories (i.e., dynamic RAM today) remain slow compared to a (high-performance) CPU core.
While many designs achieved the aim of higher throughput at lower cost and also allowed high-level language constructs to be expressed by fewer instructions, it was observed that this was not always the case. For instance, low-end versions of complex architectures (i.e. using less hardware) could lead to situations where it was possible to improve performance by not using a complex instruction (such as a procedure call or enter instruction) but instead using a sequence of simpler instructions.
One reason for this was that architects (microcode writers) sometimes "over-designed" assembly language instructions, including features that could not be implemented efficiently on the basic hardware available. There could, for instance, be "side effects" (above conventional flags), such as the setting of a register or memory location that was perhaps seldom used; if this was done via ordinary (non duplicated) internal buses, or even the external bus, it would demand extra cycles every time, and thus be quite inefficient.
Even in balanced high-performance designs, highly encoded and (relatively) high-level instructions could be complicated to decode and execute efficiently within a limited transistor budget. Such architectures therefore required a great deal of work on the part of the processor designer in cases where a simpler, but (typically) slower, solution based on decode tables and/or microcode sequencing is not appropriate. At a time when transistors and other components were a limited resource, this also left fewer components and less opportunity for other types of performance optimizations.
Hub AI
Complex instruction set computer AI simulator
(@Complex instruction set computer_simulator)
Complex instruction set computer
A complex instruction set computer (CISC /ˈsɪsk/) is a computer architecture in which single instructions can execute several low-level operations (such as a load from memory, an arithmetic operation, and a memory store) or are capable of multi-step operations or addressing modes within single instructions.[citation needed] The term was retroactively coined in contrast to reduced instruction set computer (RISC) and has therefore become something of an umbrella term for everything that is not RISC,[citation needed] where the typical differentiating characteristic[dubious – discuss] is that most RISC designs use uniform instruction length for almost all instructions, and employ strictly separate load and store instructions.
Examples of CISC architectures include complex mainframe computers to simplistic microcontrollers where memory load and store operations are not separated from arithmetic instructions.[citation needed] Specific instruction set architectures that have been retroactively labeled CISC are System/360 through z/Architecture, the PDP-11 and VAX architectures, and many others. Well known microprocessors and microcontrollers that have also been labeled CISC in many academic publications[citation needed] include the Motorola 6800, 6809 and 68000 families; the Intel 8080, iAPX 432, x86 and 8051 families; the Zilog Z80, Z8 and Z8000 families; the National Semiconductor NS320xx family; the MOS Technology 6502 family; and others.
Some designs have been regarded as borderline cases by some writers.[who?] For instance, the Microchip Technology PIC has been labeled RISC in some circles and CISC in others.
Before the RISC philosophy became prominent, many computer architects tried to bridge the so-called semantic gap, i.e., to design instruction sets that directly support high-level programming constructs such as procedure calls, loop control, and complex addressing modes, allowing data structure and array accesses to be combined into single instructions. Instructions are also typically highly encoded in order to further enhance the code density. The compact nature of such instruction sets results in smaller program sizes and fewer main memory accesses (which were often slow), which at the time (early 1960s and onwards) resulted in a tremendous saving on the cost of computer memory and disc storage, as well as faster execution. It also meant good programming productivity even in assembly language, as high level languages such as Fortran or Algol were not always available or appropriate. Indeed, microprocessors in this category are sometimes still programmed in assembly language for certain types of critical applications.[citation needed]
In the 1970s, analysis of high-level languages indicated compilers produced some complex corresponding machine language. It was determined that new instructions could improve performance. Some instructions were added that were never intended to be used in assembly language but fit well with compiled high-level languages. Compilers were updated to take advantage of these instructions. The benefits of semantically rich instructions with compact encodings can be seen in modern processors as well, particularly in the high-performance segment where caches are a central component (as opposed to most embedded systems). This is because these fast, but complex and expensive, memories are inherently limited in size, making compact code beneficial. Of course, the fundamental reason they are needed is that main memories (i.e., dynamic RAM today) remain slow compared to a (high-performance) CPU core.
While many designs achieved the aim of higher throughput at lower cost and also allowed high-level language constructs to be expressed by fewer instructions, it was observed that this was not always the case. For instance, low-end versions of complex architectures (i.e. using less hardware) could lead to situations where it was possible to improve performance by not using a complex instruction (such as a procedure call or enter instruction) but instead using a sequence of simpler instructions.
One reason for this was that architects (microcode writers) sometimes "over-designed" assembly language instructions, including features that could not be implemented efficiently on the basic hardware available. There could, for instance, be "side effects" (above conventional flags), such as the setting of a register or memory location that was perhaps seldom used; if this was done via ordinary (non duplicated) internal buses, or even the external bus, it would demand extra cycles every time, and thus be quite inefficient.
Even in balanced high-performance designs, highly encoded and (relatively) high-level instructions could be complicated to decode and execute efficiently within a limited transistor budget. Such architectures therefore required a great deal of work on the part of the processor designer in cases where a simpler, but (typically) slower, solution based on decode tables and/or microcode sequencing is not appropriate. At a time when transistors and other components were a limited resource, this also left fewer components and less opportunity for other types of performance optimizations.