¿Por qué alguien querría CISC?

En nuestra conferencia sobre sistemas informáticos, nos presentaron el procesador MIPS. Fue (re) desarrollado en el transcurso del término y, de hecho, ha sido bastante fácil de entender. Utiliza un diseño RISC , es decir, sus comandos elementales se codifican regularmente y solo hay unos pocos para mantener los cables simples.

Se mencionó que CISC sigue una filosofía diferente. Miré brevemente el conjunto de instrucciones x86 y me sorprendió. ¡No puedo imaginar cómo alguien querría construir un procesador que use un conjunto de comandos tan complejo!

Así que me imagino que tiene que haber buenos argumentos por qué grandes porciones del mercado de procesadores usan arquitecturas CISC. ¿Qué son?

Hay una tendencia histórica general.

En los viejos tiempos, los recuerdos eran pequeños, por lo que los programas eran muy pequeños. Además, los compiladores no eran muy inteligentes, y muchos programas se escribieron en ensamblador, por lo que se consideró bueno poder escribir un programa con pocas instrucciones. Las líneas de instrucciones eran simples y los procesadores tomaban una instrucción a la vez para ejecutarla. La maquinaria dentro del procesador era bastante compleja de todos modos; Las instrucciones de decodificación no se consideraron una gran carga.

En la década de 1970, los diseñadores de CPU y compiladores se dieron cuenta de que tener instrucciones tan complejas no era tan útil después de todo. Fue difícil diseñar procesadores en los que esas instrucciones fueran realmente eficientes, y fue difícil diseñar compiladores que realmente aprovecharan estas instrucciones. El área del chip y la complejidad del compilador se gastaron mejor en actividades más genéricas como registros más generales. El artículo de Wikipedia sobre RISC explica esto con más detalle.

MIPS es la arquitectura RISC definitiva, por eso se enseña con tanta frecuencia.

La familia x86 es un poco diferente. Originalmente era una arquitectura CISC destinada a sistemas con memoria muy pequeña (sin espacio para instrucciones grandes), y ha sufrido muchas versiones sucesivas. El conjunto de instrucciones x86 de hoy no solo es complicado porque es CISC, sino porque es realmente un 8088 con un 80386 con un Pentium posiblemente con un procesador x86_64.

En el mundo de hoy, RISC y CISC ya no son la distinción en blanco y negro que podrían haber sido alguna vez. La mayoría de las arquitecturas de CPU han evolucionado a diferentes tonos de gris.

En el lado RISC, algunas variantes modernas de MIPS han agregado instrucciones de multiplicación y división, con una codificación no uniforme. Los procesadores ARM se han vuelto más complejos: muchos de ellos tienen un conjunto de instrucciones de 16 bits llamado Thumb además de las instrucciones "originales" de 32 bits, sin mencionar a Jazelle para ejecutar instrucciones JVM en la CPU. Los procesadores ARM modernos también tienen instrucciones SIMD para aplicaciones multimedia: después de todo, algunas instrucciones complejas pagan.

En el lado de CISC, todos los procesadores recientes son, en cierta medida, RISC en su interior. Tienen microcódigo para definir todas estas macro instrucciones complejas. La gran complejidad del procesador hace que el diseño de cada modelo demore varios años, incluso con un diseño RISC, con la gran cantidad de componentes, con canalización y ejecución predictiva y demás.

Entonces, ¿por qué los procesadores más rápidos permanecen fuera de CISC? Parte de esto, en el caso de la familia x86 (32 bits y 64 bits), es la compatibilidad histórica. Pero eso no es todo. A principios de la década de 2000, Intel intentó impulsar la arquitectura Itanium . Itanium es un caso extremo de instrucciones complejas (sin embargo, en realidad no es CISC: su diseño se ha denominado EPIC ). Incluso elimina la idea anticuada de ejecutar instrucciones en secuencia: todas las instrucciones se ejecutan en paralelo hasta la próxima barrera. Una de las razones por las que Itanium no tomó es que nadie, ya sea en Intel o en otro lugar, podría escribir un compilador decente para ello. Ahora un buen procesador mayormente secuencial como x86_64, eso es algo que entendemos.

El conjunto de instrucciones x86 es un poco un caso especial. Creo que el 68K de Motorola y el VAX de DEC son ejemplos algo mejores de CISC. En los días de muchos códigos en lenguaje ensamblador, la gente pensaba que un ISA muy regular e inclusivo era mejor: creo que llamaron la diferencia entre el código ensamblador y la forma en que la gente pensaba en la " brecha semántica ". Teóricamente, querías un conjunto de instrucciones que coincidiera con la forma en que pensabas.

El otro gran controlador de diseño para CISC parece ser la "ortogonalidad": cada instrucción funcionaría con cada modo de direccionamiento (registro, dirección absoluta, desplazamiento relativo, etc.). Puede ver al hombre fantasma de la ortogonalidad en el diseño de API en el entorno de computación distribuida (DCE) y en CORBA. Esa idea no se limita al diseño del conjunto de instrucciones.

Una razón para CISC era tener una codificación densa para las instrucciones (la memoria era costosa) La idea completa de RISC era acelerar la CPU obteniendo las mismas instrucciones de tamaño todo el tiempo (sin paso lento y complejo "calcular el tamaño de la instrucción"), hacer que hagan cosas simples (por lo que es rápido averiguar qué hacer) . La memoria era barata. Esta área de circuitos liberados en la CPU para otras cosas (más registros, más unidades de procesamiento, por lo que se podrían hacer varias instrucciones en paralelo si fueran independientes). Como la CPU era mucho más lenta que la RAM, esto valió la pena. Pero las CPU se hicieron más rápidas (e hicieron más en paralelo, y ...) mientras que la RAM no se hizo más rápida (al menos no al mismo ritmo que el consumo de datos de la CPU debido al mayor paralelismo). Conozca la memoria caché, rápido como la CPU pero pequeña. Por lo tanto, ahora la memoria vuelve a ser premium, no por razones de costo sino por velocidad. Tiempo de avivamiento de la CISC. Mientras tanto, las CPU se volvieron más complejas, hasta el punto de que el microprocesador de hoy hace mucho de lo que hizo un compilador RISC: desglosar las operaciones en partes elementales, reordenar las instrucciones internas de RISCy para que puedan realizarse simultáneamente cuando sea posible. RISC fue calificado como "Aliviar cosas importantes para el compilador" por una razón ...

La verdadera ventaja de CISC es la reducción de la presión de memoria y caché y eso solo lo hace mejor para aplicaciones exigentes de alto rendimiento, ya que un gran cuello de botella en tales sistemas es el ancho de banda de memoria. Dada la memoria caché de igual tamaño, los procesadores CISC pueden describir más información que RISC. Además, dado que las instrucciones CISC implican varias microoperaciones, pueden ser posibles mejoras arquitectónicas que pueden proporcionar la ruta de ejecución más rápida para esa instrucción que escribir instrucciones individuales podría proporcionar. En resumen, los procesadores CISC son más eficientes al utilizar el ancho de banda de la memoria, que a menudo se traduce en ganancias de rendimiento para las aplicaciones con uso intensivo de memoria.

Por ejemplo, para realizar R1 = R2 + R3 + R4 + R5 + R6y enviar el resultado a la pila, digamos que el código RISC se escribe como,

ADD  R1, R2, R3 (4-byte)
ADD  R1, R4, R5 (4-byte)
ADD  R1, R6, R0 (4-byte, R0=0)
PUSH R1         (4-byte)

y como tal requiere 16 bytes de espacio.

Al llegar a CISC, debido a la posibilidad de diferentes estilos de codificación, la misma información puede representarse de la siguiente manera ...

ADD R1, R2, R3 (4-byte)
ADD R1, R4, R5 (4-byte)
ADD R1, R6     (2-byte)
PUSH R1        (1-byte) 

que toma solo 12 bytes de memoria. Por lo tanto, se mejora la utilización de la memoria, lo que permite al procesador ver más instrucciones y, por lo tanto, reducir los ciclos de inactividad.

Un aspecto importante que nadie ha mencionado es que casi todas las CPU CISC son arquitecturas microcodificadas. Un microsecuenciador y una tienda de control consumen mucho menos espacio inmobiliario que un controlador cableado, y el conjunto de instrucciones se puede modificar sin modificar el hardware.

Los microprocesadores eran dispositivos novedosos cuando entré en el campo. Una práctica muy común en los años setenta y principios de los ochenta era ensamblar una CPU utilizando ALU de corte de bits, una unidad de control basada en microsecuenciadores y un almacén de control en el que el conjunto de instrucciones microcodificadas se cargaba o soplaba. Estas computadoras se basaron en la lógica transistor-transistor serie 7400 (TTL). El 78181 de 4 bits ALU se usó para construir muchos procesadores, incluyendo las computadoras DEC PDP-11 y VAX 11, Data General Nova, Xerox Alto y la computadora de escritorio Wang.

Te resultará difícil encontrar una computadora de escritorio que no esté usando un procesador compatible con x86. Ese conjunto de instrucciones ha vencido a MIPS, ha vencido a Sparc, ha vencido a Alpha, ha vencido a Titanic (puedo haber escrito mal ese nombre). MIPS, por otro lado, apenas existe en la actualidad. Así que no importa lo que pienses hoy, personas muy inteligentes pensaron que el conjunto de instrucciones x86 era una muy buena idea, y han ganado mucho dinero con él.

Las computadoras comenzaron como RISC porque un conjunto complejo de instrucciones estaba más allá de las habilidades de los implementadores. Si desea ver un conjunto de instrucciones RISC, mire el conjunto de instrucciones CDC 6400-6600 y CDC Cyber ​​170-175. Eso es correcto RISC. Hace unos 10 años, pregunté a algunos diseñadores de chips cuánto espacio requeriría (en la esquina de un chip GPU avanzado razonable). Me contaron sobre 1 mm2, incluida la RAM de la máquina, que ocuparía el 99% de ese espacio.

Cuando las personas podían construir máquinas CISC, en realidad tenían una ventaja. Recuerde que x86 se lanzó mucho antes de MIPS, 1978 vs. 1985. En ese momento, necesitaba ciclos de procesador para leer las instrucciones, decodificarlas y realizarlas. MIPS en 1978 habría tomado cuatro ciclos por instrucción y por operación. Si toma una instrucción x86 como "agregar registro a la memoria", eso tomaría tal vez 7 ciclos para la instrucción, pero realiza 3 operaciones. Esa fue una gran ventaja. Y cuantas más instrucciones diferentes tenga, y cuanto más poderosa sea cada instrucción, mayor será la ventaja.

Y cuando se desarrolló el conjunto de instrucciones x86 de 64 bits con sus códigos de prefijo de pesadilla, la complejidad del conjunto de instrucciones ya no importó. CISC hoy en día solo se traduce a RISC, y todo el negocio de la traducción es quizás el uno por ciento del chip.

Esta pregunta tiene mucho que ver con las tendencias muy recientes en informática que favorecen un cambio masivo a la informática móvil y de tabletas, favoreciendo así a RISC cpus, y ha sorprendido a Intel (probablemente el proveedor de CISC más grande del mundo) en desventaja en una llamada "inflexión" punto " exactamente como el tipo que Grove llamó la atención y advirtió. La historia corta es que CISC parece estar comenzando a derretirse bajo el ataque masivo de cambio de paradigma / cambio de juego de la informática móvil debido a su consumo de energía aparentemente intrínsecamente alto.

Presumiblemente, CISC siempre estará presente en el escritorio, pero el móvil es ampliamente considerado como el nuevo futuro de la informática. Muchos países en desarrollo (con grandes poblaciones potenciales que usan computadoras) en realidad omitirán en gran medida la fase de escritorio. Ver, por ejemplo, Auge y caída de la informática de escritorio

Un excelente caso de estudio de esta pregunta es leer sobre Mike Bell, que está trabajando para Intel en una nueva posición que intenta posicionar a Intel mejor en el mercado móvil a través de la CPU Atom a través de un proyecto / iniciativa tipo "skunkworks", con un ejecutivo muy fuerte. apoyo. El mercado móvil está estrechamente vinculado a la arquitectura RISC, y principalmente a los procesadores ARM, debido en gran parte a su alta eficiencia energética (consumo de energía), un nuevo criterio clave para la computación que la pregunta y ninguna otra respuesta mencionan. Aquí hay dos artículos recientes en este sentido que revelan mucho del pensamiento corporativo interno (¡y la consiguiente lucha!) Sobre el tema:

• Intel rechaza el 'impuesto x86', no ve futuro para ARM o cualquiera de sus competidores

• Un imperio contraataca: Intel entra en el mercado móvil

Un factor no mencionado en otras respuestas es el económico. También se trata de Intel. La arquitectura CISC está representada en gran medida por las familias x86 y x64. Todos estos descienden del humilde 8088 utilizado en la PC original de IBM. El dominio temprano del mercado de esa serie de computadoras significaba que Intel tenía un flujo de ingresos sólido para I + D. Junto con el hecho de que Intel fue capaz de frenar la competencia al incumplir / cancelar sus acuerdos de segunda fuente, los precios de la CPU podrían elevarse a niveles extremos para garantizar márgenes de beneficio bruto muy ricos.

Por lo tanto, mientras que otros fabricantes de CPU lucharon por mantener el ritmo, Intel pudo invertir miles de millones de dólares en el desarrollo de productos más nuevos y más rápidos. La competencia RISC no podía gastar tanto dinero. Muchos procesadores RISC salieron del mercado. Algunos fueron:

DEC Alpha, Fairchild Clipper, AMD 29000, SPARC, MIPS, POWER (para uso en PC), Hitachi SuperH ...

Recuerdo que expertos de esa época anunciaron que la guerra RISC vs CISC había terminado y que CISC había ganado. No lo hizo. Simplemente superó a todos los demás.

¿Puede esta dinámica cambiar alguna vez? Ya lo es. Ninguna ventaja económica es absoluta.

El único talón de Aquiles del x86 es su apetito voraz por el poder. Esto ha permitido que un competidor (ARM) más pequeño y ágil prospere en los mercados (como teléfonos / tabletas / etc.) donde importaba el ahorro de energía.

Un gran video sobre esto de un miembro del equipo ARM es ARM Processor - Sembrando las semillas del éxito - Computerphile alrededor de las 8:30

El segundo problema para x86 es el éxito de la estrategia de Intel. Se las arreglaron para eliminar casi toda la competencia. Disminuyeron la velocidad. Durante años, los nuevos procesadores Intel han entregado solo mejoras muy modestas. Peor aún, los márgenes súper ricos son una dieta difícil de abandonar para cualquier empresa.

Hoy, los sistemas basados ​​en ARM en chip (SOC) y los chips x64 competidores de AMD están nuevamente haciendo del mercado de CPU un lugar interesante. (EN MI HUMILDE OPINIÓN)

Hay muchas razones por las que uno elegiría implementar un CISC. La razón más destacada es la compatibilidad binaria con un conjunto de instrucciones CISC existente. Si bien la tecnología de traducción binaria de software ha mejorado, la compatibilidad basada en hardware tiene algunas ventajas técnicas (así como la desventaja de un menor almacenamiento en caché de traducción) y la menor ventaja técnica de parecer más confiable.

La densidad del código es quizás la segunda razón más importante para elegir CISC. El Renesas RX fue diseñado como un CISC específicamente para la densidad del código, ya que se dirige a los microcontroladores donde el tamaño de la memoria del código es un factor de costo significativo. Las instrucciones de longitud variable, las instrucciones complejas (principalmente más modos de direccionamiento), los operandos implícitos y el registro más bajo cuentan toda la densidad del código de beneficio.

Una razón histórica (y en mi opinión equivocada) para elegir CISC fue cerrar la brecha semántica entre los programadores que usan un lenguaje de nivel superior y el procesador. Dado que las instrucciones complejas generalmente se pueden reemplazar por una secuencia de instrucciones más simples, la complejidad de un compilador de lenguaje de nivel superior para un RISC no necesita ser mucho más compleja que para un CISC de coincidencia de idiomas. RISC evita el "choque semántico" (donde una instrucción de procesador hace más o menos trabajo que una declaración de lenguaje correspondiente) y facilita la reducción de fuerza y ​​las optimizaciones de programación. (Ver "¿Cuáles son las ventajas y desventajas en el esfuerzo de desarrollo compilador relacionada con CISC vs RISC?" Para más detalles).

Puede haber un costo fijo significativo asociado con la ejecución de una instrucción. Esto fomenta el uso de instrucciones relativamente complejas para distribuir esta sobrecarga en un trabajo más real; La reducción del recuento dinámico de instrucciones puede mejorar el rendimiento. Cuando el costo de la lógica y la RAM era mucho mayor que el costo de la ROM, el incentivo para instrucciones complejas era significativo ya que una instrucción se decodificaba al buscar el microcódigo.

Una razón para usar CISC que tal vez se contradice con la evidencia histórica es que el microcódigo se puede optimizar para cada microarquitectura, mientras que las bibliotecas estándar pueden ser lentas para explotar las características de una nueva implementación. El nivel de optimización de las implementaciones de software de memcopy versus el del microcódigo para REP MOVSB ​​implica que las bibliotecas pueden obtener más atención que el microcódigo. Parte de esto puede provenir del proveedor del procesador dirigido a una base de usuarios más amplia, por lo que la justificación del esfuerzo puede ser más difícil en comparación con el software de código abierto o interno donde los intereses localizados de los desarrolladores o usuarios pueden sesgar el esfuerzo de implementación.

Ser capaz de enviar una biblioteca estándar optimizada con el procesador tiene importantes atracciones. El almacenamiento y la ejecución de una biblioteca estándar de plataforma se pueden optimizar significativamente mediante el código de código de hardware y software. La distinción entre una instrucción compleja y una llamada de Capa de abstracción de plataforma puede ser sutil (o inexistente). Un diseño RISC podría usar las mismas técnicas de implementación para manejar llamadas PAL que un CISC para instrucciones complejas, incluido el uso de operaciones que no se proporcionan en el conjunto de instrucciones generales con hardware especializado, el uso de caché y decodificación inteligentes, y la especificación de operandos de registro (aunque un CISC lo haría a menudo usan registros dedicados similares a un ABI por función). El modelo mental asociado con CISC puede fomentar tales optimizaciones. Además, los usuarios pueden sentirse menos ofendidos por la inclusión forzada de un "

La decodificación de instrucciones relativamente complejas puede tener menos sobrecarga (y posiblemente sea más confiable en la intención de discernir) que la técnica RISC comparable de reconocimiento de idiomas donde una secuencia de instrucciones se reconoce como una unidad semántica. Esta diferencia de gastos generales sería más notable en una implementación más pequeña, pero los gastos generales para usar esta información reducen la importancia de los ahorros de decodificación.

La información contextual adicional puede facilitar la optimización del hardware. Por ejemplo, al incrementar un valor en la memoria, el hardware podría reconocer que la dirección de la memoria se usa dos veces (para la carga y la tienda), lo que brinda una oportunidad para la memoria caché y el almacenamiento en caché de la traducción. Las instrucciones complejas pueden proporcionar dicha información explícitamente. En una instrucción compleja, los valores intermedios tienen una vida útil explícita (la de la instrucción); con un registro RISC tradicional, los valores deben sobrescribirse explícitamente para indicar el final de la vida. (Nota: Un RISC podría especificar un registro que siempre se pone a cero después de cada uso, proporcionando un medio para especificar un valor temporal de un solo uso. Dichas instrucciones serían moderadamente más complejas).

Si los detalles de implementación no están ocultos detrás de una capa de abstracción, se hace más difícil usar diferentes microarquitecturas para optimizar las diferentes compensaciones. La exposición de detalles microarquitectónicos como garantías arquitectónicas bloquea la microarquitectura en la garantía de compatibilidad. Si bien el software PAL podría optimizarse de la misma manera que las instrucciones complejas, esto requiere un código de hardware y software. La separación organizacional y la diversidad hacen que el código sea más difícil.

Las instrucciones complejas pueden proporcionar acceso protegido al estado privilegiado. Por ejemplo, las instrucciones complejas son a menudo atómicas con respecto a las interrupciones. Si bien un conjunto de instrucciones RISC podría proporcionar un mecanismo a nivel de usuario para suspender temporalmente las interrupciones, posiblemente incluso algo así como la carga vinculada para que el software vuelva a intentar explícitamente la operación si se interrumpe, siempre que no sea típico para los RISC.

Del mismo modo, una instrucción compleja podría proporcionar acceso controlado y / o uso de información privilegiada. Debido a que la operación ejecutada tiene semántica controlada, se puede evitar la violación real de privilegios. Las alternativas orientadas a RISC incluyen el código PAL (que generalmente tiene una sobrecarga significativa) y el acceso enmascarado a los registros de configuración (o instantáneas de registros) que tienen algún estado privilegiado. Proporcionar una solución general (RISC) es más difícil que proporcionar una solución a uno o algunos casos especiales (CISC), pero es más poderoso y menos vulnerable a la acumulación de casos especiales. Si uno cree que los casos especiales importantes son pocos, CISC puede ser más atractivo.

Las instrucciones complejas también pueden ocultar el estado del software. Una ventaja destacada de esto sería para guardar y restaurar el contexto. Con instrucciones que guardan y restauran el estado, la arquitectura solo necesita comunicar el tamaño del contexto al sistema operativo, no los mecanismos específicos para transferir el estado a la memoria. Esto permite que las aplicaciones que se ejecutan en un sistema operativo heredado usen extensiones ISA que agregan estado. (Nuevamente, el software PAL podría proporcionar la misma funcionalidad).

Gran parte de la complejidad de x86 proviene de la compatibilidad en muchas extensiones. Con instrucciones complejas y menos ortogonales (útiles para la densidad de código), eliminando algunos trabajos que resultaron no ser comúnmente necesarios, evitando cadenas de dependencia innecesarias (por ejemplo, solo un bit de acarreo, solo un registro de cantidad de desplazamiento dinámico), agregando algo de trabajo que resultó fuera de uso común y que puede optimizarse dentro de la instrucción compleja: cualquiera de estos requeriría agregar una nueva instrucción y hacer que el ISA sea menos estéticamente agradable.

En muchos casos, un RISC no encontraría tales problemas porque las instrucciones son altamente ortogonales y primitivas. En algunos casos, un RISC podría necesitar agregar nuevas primitivas, pero normalmente sería aplicable a más de un uso.

Además, una vez que la infraestructura está en su lugar para soportar instrucciones complejas, las barreras se reducen para obtener instrucciones complejas adicionales. Es decir, gran parte del costo de instrucciones complejas no recurrentes. Los ISA RISC sufren un obstáculo complementario a la introducción de las características CISCy.

La frecuencia de extensión de x86 también puede atribuirse parcialmente a su popularidad para la informática de propósito general y el modelo de procesador comercial (esto también aumenta la importancia de la compatibilidad binaria). Los ISA RISC a menudo se han vinculado a proveedores de sistemas que fomentan un enfoque más limitado en las aplicaciones y la falta de competencia para la implementación de un ISA RISC específico desalienta el uso de extensiones de conjuntos de instrucciones para el marketing. La popularidad también hace que el costo de desarrollar nuevas extensiones sea menos significativo (los gastos no recurrentes son menos importantes a un volumen mayor).

La filosofía de compatibilidad x86 probablemente también sesga hacia la ampliación de los mecanismos existentes en lugar de proporcionar un descanso más limpio, lo que significa que las nuevas funciones están más influenciadas por las existentes. Una mayor frecuencia de extensión también fomenta cambios más incrementales, lo que fomenta la reutilización de mecanismos y tiende a reducir la ortogonalidad.

Comparando una presentación académica de MIPS clásico (que es un subconjunto de versiones modernas de MIPS y excluye varias extensiones ISA opcionales) a x86 moderno (que rastrea la compatibilidad binaria hasta el 8086 de 16 bits y la cuasi-compatibilidad de nivel de ensamblaje aún más atrás) con todo su equipaje histórico no presenta el mejor caso para CISC ni un caso realista para RISC.

Simplemente antes de que hubiera Configuraciones de conjuntos de instrucciones reducidas, había Configuraciones de conjuntos de instrucciones. Tienen sus aplicaciones. particularmente en transferencias de bloques de memoria muy grandes con conjuntos de chips de alta capacidad, que solo necesitarían de 4 a 16 bytes para transferir una página de video completa, en lugar de un bucle largo para siempre. eso está cambiando y RISC se está convirtiendo en el status quo a medida que los conjuntos de chips se vuelven más sofisticados, como las increíbles GPU que se encuentran en las tarjetas de video de gama alta.

La CPU CISC tiene más ventajas que la RISC. ¡Porque CISC usa menos registro de hardware y puertas XNOR / XOR que RISC muchas veces! Imagine que los bytes de instrucción en CISC se ejecutarán en secuencia, solo hay una puerta lógica y se utiliza el registro. Si los transistores de 1 billón pueden producir alrededor de 300 millones de puertas lógicas, entonces puede procesar 300 millones de operadores o procesos (IF, igual, matemático, variable, direccionamiento ... etc.) y se puede ejecutar más programa en CISC. Pero en RISC, se necesitan docenas de puertas lógicas para ejecutar un programa en diseño canalizado. ¡Así que 300 millones x 50 veces (50 instrucciones) + contadores de 15000000000 bits! en el llamado RISC. CISC usa más hardware para reducir el software algothrim que ralentiza la CPU.