Los tiempos verbales son un poco extraños aquí. Tal vez deberían unificarse en tiempo presente a menos que el tiempo pasado sea realmente apropiado. —Comentario anterior sin firmar agregado por Qbeep ( discusión • contribuciones ) 01:26, 9 abril 2009 (UTC) [ responder ]
Fecha
¿Es realmente necesaria la fecha ("1994-10-10") que aparece al final de la página? Creo que es la fecha de la entrada de FOLDOC en la que se basa este artículo. No veo por qué sigue siendo relevante. Voy a quitarla, pero si sirve para algún propósito, adelante, vuelva a colocarla. James Foster 09:57, 24 de noviembre de 2004 (UTC)
"Por ejemplo, en un procesador se descubrió que era posible mejorar el rendimiento al no utilizar la instrucción de llamada a procedimiento, sino utilizando en su lugar una secuencia de instrucciones más simples".
¿A qué procesador se refiere exactamente el autor? ¿O simplemente lo inventó? ¡REFERENCIAS!
- El procesador probablemente era el VAX y la instrucción de llamada era probablemente CALLG o CALLS. Recuerdo que esto se discutió hace mucho tiempo en los primeros días del RISC moderno. Desafortunadamente, no tengo una referencia en este momento (o no está disponible en Google o está enterrada en el lío de páginas que coinciden con una búsqueda de "vax performance callg calls jsr"), pero sospecho que se puede encontrar una referencia. Seguiré buscando (o usted, o alguien más, podría encontrarla). Guy Harris 07:08, 1 de febrero de 2006 (UTC) [ responder ]
- Encontré un ejemplo similar con la instrucción de índice VAX-11/780 que es más lenta que una secuencia de instrucciones equivalente y más simple. Consulte: http://www.pattosoft.com.au/jason/Articles/HistoryOfComputers/1970s.html (tercer párrafo antes del último). Esto también se menciona en el libro "Computer Organization & Design" de Patterson y Hennessy, 1.ª edición (página 350). Si no puede encontrar la referencia para su ejemplo original, tal vez pueda usar esto y vincularlo a la página web que mencioné. Rogerbrent 18:40, 1 de febrero de 2006 (UTC) [ responder ]
No lo sé. Agregué el libro Structured Computing Organization de Tanenbaum que usé en mi clase de ensamblaje hace dos años, ya que la sección de la página 58-59 respalda la mayor parte de este artículo. Flying Bishop ( discusión ) 15:49 9 may 2009 (UTC) [ responder ]
Este artículo lo da como ejemplo de un procesador CISC, pero la página del CDC 6600 dice: "La base de la CPU 6600 es lo que hoy llamaríamos un sistema RISC, en el que el procesador está ajustado para ejecutar instrucciones que son comparativamente simples y tienen un acceso limitado y bien definido a la memoria". Si mal no recuerdo, tenía instrucciones de longitud fija, solo modos de direccionamiento simples y una arquitectura de carga/almacenamiento, que suena más a RISC que a CISC; ¿cómo se puede considerar un procesador CISC? Guy Harris 19:33, 19 de febrero de 2006 (UTC) [ responder ]
No. No se puede considerar un procesador CISC. He eliminado la referencia.-- Wws 18:08, 30 de octubre de 2006 (UTC) [ responder ]
Dave Patterson (y John Hennessey) citan el 6600 como precursor del modelo RISC. Véase la nota de referencia (Dave dijo que lo hiciera). Pero otras series posteriores de CDC Cyber, como 203 y 205, podrían considerarse CISC o incluso VCISC. 143.232.210.150 (discusión) 22:32 23 mar 2012 (UTC) [ responder ]
Metas y diferencias
La naturaleza de RISC no es sólo que utiliza instrucciones simples, sino que mantiene la simplicidad del chip . CISC no hace ningún esfuerzo por simplificar el chip: busca la velocidad y la capacidad y sólo utiliza la simplicidad cuando es más rápida.
En el desarrollo de arquitecturas, el término RICH significaba Rich Instruction Chip (chip de instrucción enriquecida), lo que implicaba que las instrucciones de máquina individuales eran potencialmente extremadamente poderosas y a veces competían con las instrucciones del compilador. En la década de 1980, CISC suplantó a RICH en la prensa especializada, aunque considero que RICH es un acrónimo más descriptivo (y más inteligente) que CISC.
Esto merece ser mencionado en el artículo del CISC, aunque no creo que RICH merezca un artículo aparte.
-- UnicornTapestry ( discusión ) 23:53 6 dic 2007 (UTC) [ responder ]
- [ cita requerida ] Guy Harris ( discusión ) 00:19 7 dic 2007 (UTC) [ responder ]
No todos los CISC están microcodificados o tienen instrucciones "complejas" (en comparación con un Z80, la división de 32 bits del MIPS o cualquier instrucción de punto flotante RISC son extremadamente complejas) y no es la cantidad de instrucciones ni la complejidad de la implementación o de las instrucciones en sí mismas lo que distingue a un CISC de un RISC, sino los modos de direccionamiento y el acceso a la memoria. CISC es un término general que significa cualquier cosa que no sea una arquitectura de carga y almacenamiento (RISC). Un PDP-10, un PDP-8, un Intel 386, un Intel 4004, un Motorola 68000, un mainframe System z, un Burroughs B5000, un VAX, un Zilog Z80000 y un 6502 varían enormemente en la cantidad, los tamaños y los formatos de las instrucciones, la cantidad, los tipos y los tamaños de los registros y los tipos de datos disponibles. Algunos tienen soporte de hardware para operaciones como escanear una subcadena, aritmética BCD de precisión arbitraria o calcular una arcotangente, mientras que otros tienen solo suma y resta de 8 bits. Pero todos son CISC porque tienen instrucciones de "carga-operación" que leen de la memoria y realizan un cálculo al mismo tiempo. El PDP-8, que tiene solo 8 instrucciones de longitud fija y ningún microcódigo, es un CISC debido a cómo funcionan las instrucciones (por ejemplo, buscar en la memoria y calcular una adición a la vez), pero PowerPC, que tiene más de 230 instrucciones (más que algunos VAX) y componentes internos complejos como el cambio de nombre de registros y un búfer de reordenamiento, es un RISC. Este CISC mínimo tiene 8 instrucciones, pero es claramente un CISC porque combina el acceso a la memoria y el cálculo en las mismas instrucciones. 76.205.121.173 (discusión) 08:51 30 may 2011 (UTC) [ responder ]
- Estoy totalmente de acuerdo, pero leí la "definición" en la introducción (última edición importante hecha por mí). No veo que contradiga tus puntos de vista de ninguna manera. Sin embargo, encuentro que tu texto está bien redactado, casi apto para incluirlo en el artículo tal como está aquí. 83.255.33.7 ( discusión ) 00:04 3 jun 2011 (UTC) [ responder ]
La mayor parte de la discusión en esta página es sobre máquinas históricas, pero ¿no debería haber algo sobre cómo CISC fue reemplazado por RISC debido al énfasis en la segmentación para lograr eficiencia, el fracaso de los escritores de compiladores para generar código de máquina que realmente utilizara la instrucción CISC más complicada y que las arquitecturas CISC violaron la ley de Amdahl en términos de la mayor rentabilidad por cada dólar invertido? — Comentario anterior sin firmar agregado por 173.66.233.28 (discusión) 05:49, 30 de diciembre de 2013 (UTC) [ responder ]
- Dado que la arquitectura principal del conjunto de instrucciones para computadoras personales de escritorio y portátiles, y dos de las arquitecturas de conjuntos de instrucciones más importantes para servidores, son CISC, no estoy seguro de que RISC la haya "sustituido" completamente, aunque la arquitectura principal del conjunto de instrucciones para teléfonos inteligentes y tabletas es RISC, y una gran cantidad de informática integrada utiliza varias arquitecturas RISC.
- La sección "La idea RISC" menciona la segmentación; el punto sobre los compiladores que no utilizan algunos aspectos de CISC se menciona en la sección "Utilización del hardware" del artículo sobre computación con conjunto de instrucciones reducido .
- La ley de Amdahl no parece decir nada acerca de la rentabilidad; analiza la aceleración disponible para un programa en particular al paralelizarlo (lo que se aplica a CISC o RISC).
En lugar de decir que el CISC fue reemplazado, habría sido más preciso decir que el RISC lo sucedió en el desarrollo de las arquitecturas modernas y que las arquitecturas antiguas dejaron de ejecutar instrucciones CISC directamente y comenzaron a dividir las instrucciones CISC en "microoperaciones" RISC como parte de su ejecución. Las arquitecturas Intel x86 e IBM360 entran en esta categoría. La presencia de estas arquitecturas antiguas en computadoras de escritorio, servidores y mainframes es cierta, pero creo que son sistemas RISC que tienen un preprocesador para soportar el código CISC antiguo. Conceptualmente hablando, el CISC no es un competidor del RISC por las razones mencionadas anteriormente. La Ley de Amdahl es muy importante en la segmentación, pero su forma general dice que la mejora máxima esperada para un sistema general está restringida cuando solo se mejora una parte del sistema. Por lo tanto, dedicar la lógica de un chip a las instrucciones CISC es una mala elección cuando rara vez se utilizan (debido a los compiladores) y no se pueden canalizar (debido a los tiempos de ejecución muy variables). Básicamente, creo que la sección no menciona que RISC ganó la guerra CISC/RISC. — Comentario anterior sin firmar añadido por 151.151.16.22 ( discusión ) 19:42, 3 enero 2014 (UTC) [ responder ]
- Dado que los programadores no pueden escribir código uop para x86 o z/Architecture, y los compiladores no pueden escribir código uop para x86 o z/Architecture, las arquitecturas "heredadas" siguen siendo relevantes.
- En cuanto a lo RISC que son las microoperaciones, tenga en cuenta que, con la fusión de microoperaciones, las microoperaciones no son tan micro; esa página habla de combinar una instrucción de comparación y una bifurcación condicional en una única microoperación y de combinar las microoperaciones de carga y adición de ADD [mem], EAX en una única microoperación. Esto último se aleja un poco del aspecto de la arquitectura de carga y almacenamiento de RISC.
- Así que la única forma en que RISC "ganó" es que las unidades de despacho, programación y ejecución en los procesadores modernos son más simples que algunas de las instrucciones en los procesadores CISC actuales; las unidades de código generado, sin embargo, siguen siendo CISC en esos procesadores, incluso si los compiladores sólo utilizan algunas de las partes CISCy (aritmética de memoria-registro y registro-memoria, doble indexación en operandos de memoria, tal vez llamadas a procedimientos CISCier en algunos casos, tal vez instrucciones decimales y de cadena en z/Architecture o pares de instrucciones REP/xxx en x86) e ignoran las otras partes CISCy (a las que no se les asignan muchos transistores), e incluso algunas de las unidades de despacho, programación y ejecución podrían combinar una referencia de memoria y una operación aritmética (fusión de microoperaciones).
- El único ISA RISC que "ganó", en informática de propósito general, hasta el punto de desplazar a los competidores o dejarlos fuera en primer lugar es ARM (no hay muchos teléfonos inteligentes o tabletas Atom por ahí); los otros perdieron en el mercado de computadoras de escritorio y portátiles (será interesante ver si ARM vuelve allí) y están compitiendo con x86-64 y z/Architecture en el mercado de servidores. Los otros perdieron en el mercado de computadoras de escritorio y portátiles en gran medida porque Intel (y, en menor medida, AMD) tenían el dinero para lanzar transistores a decodificadores que convertían las instrucciones x86 en secuencias uop; dedicar la lógica de un chip a hacer eso es una muy buena opción si significa que se mantiene a PowerPC, MIPS, SPARC y PA-RISC fuera de un mercado lucrativo.
- Otra forma de pensarlo es que la primera "C" de "CISC" se dividió en "las cosas que necesitamos hacer que funcionen rápido, porque los programadores y compiladores las usan mucho" y "las cosas que no se usan lo suficiente, por lo que simplemente tienen que funcionar, no ir rápido", con las primeras cosas hechas para "ir rápido" con técnicas como dividirlas en uops, y las últimas cosas dejadas, pero con la fracción del chip usado para implementarlas haciéndose más pequeña con el tiempo. Esa división es una victoria para algunas de las ideas que motivaron RISC, pero con el proceso de "reducción" que no requiere, por ejemplo, una arquitectura de carga y almacenamiento. Guy Harris ( discusión ) 22:29 3 enero 2014 (UTC) [ responder ]
Me parece que en lugar de "instrucción", el artículo de CISC debería utilizar en general el término "código de operación" u "operación especificada por un código de operación". No todas las máquinas tienen solo un código de operación por instrucción, y me parece que el mero hecho de que una arquitectura permita múltiples códigos de operación por instrucción no debería obligarla a etiquetarse como CISC. En otras palabras, si cargar, agregar y almacenar requieren códigos de operación separados, la máquina debería etiquetarse como RISC, incluso si la arquitectura permite que esos tres códigos de operación aparezcan juntos en la misma instrucción. Por lo tanto, yo propondría una redacción como esta:
- una computadora en la que una sola operación (dictada por un solo código de operación) puede ejecutar varias operaciones de bajo nivel (como una carga desde la memoria, una operación aritmética y un almacenamiento de memoria) y/o es capaz de realizar operaciones de múltiples pasos o modos de direccionamiento dentro de operaciones individuales.
O bien, ¿qué tal esta declaración más concisa?:
- una computadora en la que una sola operación (dictada por un solo código de operación) puede ejecutar una carga desde la memoria, una operación sobre los datos cargados y un almacenamiento del resultado.
Enciclopedista ( discusión ) 18:55 25 ago 2011 (UTC) [ responder ]
- Bien, ¿cuáles son sus definiciones de "operación", " código de operación " e " instrucción " aquí? ¿Es un "código de operación" lo que especifica la página de Wikipedia:
- En informática, un código de operación es la parte de una instrucción en lenguaje de máquina que especifica la operación que se debe realizar.
- ¿O es otra cosa? ¿Una "operación" es algo especificado por un código de operación o es una operación de bajo nivel? Guy Harris ( discusión ) 00:25 26 ago 2011 (UTC) [ responder ]
- A ver si la reescritura anterior de mi nota es más clara Encyclopedant ( discusión ) 07:30 6 septiembre 2011 (UTC) [ responder ]
- Todavía hablas de instrucciones con múltiples códigos de operación. Por favor, dame un ejemplo de esto. Guy Harris ( discusión ) 17:33 6 sep 2011 (UTC) [ responder ]
- ¿Estás pensando en VLIW ? Guy Harris ( discusión ) 21:36 7 sep 2011 (UTC) [ responder ]
- No tengo libertad para dar un ejemplo por ahora, pero ¿qué pasaría si existiera un VLIW que tuviera las propiedades que estoy postulando? Encyclopedant ( discusión ) 00:27 15 sep 2011 (UTC) [ responder ]
- Entonces, presumiblemente, si esta nueva máquina finalmente sale al mercado, las páginas de instrucciones y códigos de operación (ciencias de la computación) se actualizarán para tenerlo en cuenta.
- "una computadora en la que una sola operación (dictada por un solo código de operación) puede ejecutar varias operaciones de bajo nivel (como una carga desde la memoria, una operación aritmética y un almacenamiento de memoria) y/o es capaz de realizar operaciones de múltiples pasos o modos de direccionamiento dentro de operaciones individuales" usa "operación" en dos sentidos separados, por lo que es potencialmente confuso. "una computadora en la que una sola operación (dictada por un solo código de operación) puede ejecutar una carga desde la memoria, una operación en los datos cargados y un almacenamiento del resultado" es mejor, aunque parece implicar que, para ser un procesador CISC, debe poder hacer una carga y un almacenamiento en una sola operación de máquina, y muchos CISC no hacen eso. Podría sentirme tentado a cambiar la oración inicial para decir "donde las operaciones de una sola máquina (especificadas por un solo código de operación ) pueden ejecutar varias operaciones de bajo nivel... y/o son capaces de operaciones de múltiples pasos o modos de direccionamiento dentro de operaciones de una sola máquina", es decir, simplemente reemplazar "instrucción" por "operación de máquina" y, la primera vez que se usa "operación de máquina", notar que una "operación de máquina" es lo que se especifica por un solo código de operación. Guy Harris ( discusión ) 18:56, 15 de septiembre de 2011 (UTC) [ responder ]
Este artículo es principalmente una opinión personal y una investigación original, en lugar de información de fuentes confiables. Por ejemplo, el artículo equipara RISC con la arquitectura de carga y almacenamiento, que no coincide con las definiciones publicadas de RISC. Esta definición ahistórica conduce a conclusiones extrañas como que el Intel 4004 es un CISC. Si bien sería bueno tener una definición sencilla en la que la combinación de aritmética y acceso a la memoria = CISC, ese no es el caso. Podría ser WP:BOLD y eliminar todas las declaraciones no citadas, pero no quedaría mucho, por lo que aliento a las personas a citar fuentes confiables. KenShirriff ( discusión ) 02:39, 24 de junio de 2023 (UTC) [ responder ]
- ¿ Se utiliza actualmente RISC en algún sentido técnico que no sea el de "arquitectura de carga/almacenamiento"? (Se suele utilizar como término de marketing , como en "CISC: cansado; RISC: conectado", pero ese es otro asunto).
- "No utiliza microcódigo" ya no es una definición tan significativa de "RISC". La serie Honeywell 6000 estaba cableada pero tenía algunas instrucciones bastante complejas, especialmente en máquinas con la caja EIS, y el IBM System/360 Modelo 75 estaba cableado e implementaba el conjunto completo de instrucciones S/360, completo con aritmética decimal, ED/EDMK, TRT, etc. Además, no estoy seguro de que ningún procesador z/Architecture actual tenga algo que se pueda considerar "microcódigo" - tienen millicode , pero eso es, según tengo entendido, más cercano a PALcode , y aparentemente también tienen código "i370"/"i390", que está en algún lugar por encima de millicode pero todavía se usa para implementar algunas características arquitectónicas; ambos son subconjuntos del código de máquina z/Architecture, con millicode siendo capaz de ejecutar instrucciones especiales dependientes del chip para realizar ciertas funciones. El Intel 80486 ejecutaba algunas instrucciones directamente en el hardware; En Pentium Pro y posteriores, tengo la impresión de que el motor de microcódigo genera microoperaciones que van al mismo programador que las microoperaciones generadas por el decodificador de instrucciones.
- "Todas las instrucciones toman un tic de reloj" ya no funciona a menos que tenga no sólo un multiplicador combinatorio de un ciclo sino también un divisor combinatorio de un ciclo, dado que muchos conjuntos de instrucciones "RISC" tienen instrucciones de multiplicación y división de números enteros y de multiplicación y división de punto flotante.
- Las "instrucciones de longitud fija" pueden funcionar mejor, pero al menos algunas arquitecturas que se denominan "RISC" tienen instrucciones comprimidas (Thumb/Thumb-2/T2, como sea que se llamen en Power ISA, como sea que las llame RISC-V).
- "Sin instrucciones complejas" podría funcionar, pero requiere una definición de "complicado", y S/360, por ejemplo, puede haber tenido ED/EDMK (probablemente la instrucción más complicada, tanto por la descripción como por la noción de "¿es esto solo un intento de convertir alguna construcción de lenguaje de programación en una sola instrucción?"), pero sus instrucciones de llamada a procedimiento BAL/BALR son bastante similares a las que tienen la mayoría de los procesadores RISC (rellena la siguiente instrucción PC en un registro y salta; deja que quien o lo que sea que genere el código para la instrucción llamada decida qué más hacer). "Sin modos de direccionamiento complejos" es similar, a menos que consideres la indexación doble, presente tanto en x86 como en S/3x0, "demasiado compleja para RISC".
- En cuanto a "CISC", como señala el artículo, fue acuñado retroactivamente, y en esencia significa "no RISC"; si "RISC" se interpreta de manera suficientemente restringida, "CISC" cubriría entonces un rango bastante amplio.
- Entonces, sí, si existen definiciones ampliamente aceptadas (con fuentes que demuestren esa amplia aceptación) de RISC y CISC, eso funcionaría, pero, en ausencia de eso, no estoy seguro de qué se podría hacer aquí. Guy Harris ( discusión ) 05:27 24 jun 2023 (UTC) [ responder ]
- Y el libro de Patterson y Ditzel "The Case for the Reduced Instruction Set Computer", que puede haber sido el origen de los términos "RISC" y "CISC", no parece ofrecer definiciones firmes de ninguno de los dos términos. Ofrece ejemplos individuales de complejidad, pero no una definición amplia de "complejidad" o reducción de la misma. (Si alguien mirara VAX y luego el anuncio posterior a la función avanzada S/370 (posterior a la función avanzada, por lo que ambos tienen MMU paginadas), y no mira las instrucciones de E/S S/370, bien podría concluir que el último tiene menos complejidad que el primero - instrucciones de llamada a procedimiento mucho más simples, menos modos de direccionamiento y ninguno que modifique registros, e incluso una versión más simple de las instrucciones de aritmética decimal/procesamiento de cadenas/"esto es para hacer COBOL y PL/I PICTUREs").
- Por lo tanto, este artículo podría considerarse una fuente confiable , pero no una fuente muy útil para el objetivo de definir claramente RISC o CISC.
- Y la sexta edición de un libro que John Hennessy coescribió con otro investigador :-) no utiliza, como señalé en esta edición, los términos "RISC" o "CISC", por lo que ahora puede ser más un caso de "RISC: cansado, arquitectura de carga y almacenamiento: cableado" y "CISC: cansado, arquitectura sin carga y almacenamiento: cableado". Guy Harris ( discusión ) 06:36 24 jun 2023 (UTC) [ responder ]
- Sí, ese es el punto. RISC y CISC eran términos vagos en los años 1980 y 1990 con múltiples definiciones contradictorias. Desde entonces, los avances en arquitecturas informáticas han hecho que los términos sean menos relevantes y que las definiciones carezcan de sentido.
- Como dijo Steve Furber (codiseñador de ARM) en VLSI RISC Architecture and Organization , "Una computadora de conjunto de instrucciones reducidas (RISC) es miembro de una clase mal definida de máquinas de computación. El factor común que asocia a los miembros de la clase es que todos tienen conjuntos de instrucciones que se han optimizado más hacia la eficiencia de implementación que los miembros de la clase alternativa de computadoras de conjunto de instrucciones complejas (CISC), donde la optimización está orientada a la minimización de la brecha semántica entre el conjunto de instrucciones y uno o más lenguajes de alto nivel".
- Por otra parte, Blaau y Brooks dicen en Computer Architecture : "Una arquitectura en la que la mayoría de las operaciones, si no todas, se pueden implementar en una única acción de ruta de datos y que tiene pocas construcciones se denomina computadora de conjunto de instrucciones reducido (RISC). Los primeros ejemplos son STC ZEBRA, DEC PDP8 y microprocesadores de primera generación como Intel 8008 y Motorola 6800".
- Y luego tienes las definiciones extremadamente cuantitativas como Tabak en la arquitectura RISC :
- 1. Número relativamente bajo de instrucciones, preferiblemente menos de 100
- 2. Número reducido de modos de direccionamiento, preferiblemente 1 o 2
- 3. Número reducido de formatos de instrucciones, preferiblemente 1 o 2, todos de la misma longitud.
- 4. Ejecución de todas las instrucciones en un solo ciclo
- 5. El acceso a la memoria se realiza únicamente mediante carga/almacenamiento;
- 6. Conjunto de registros relativamente grande, más de 32, la mayoría de las operaciones de registro a registro.
- 7. Unidad de control cableada (puede microprogramarse a medida que se desarrolle la tecnología)
- 8. Esfuerzo para apoyar las operaciones de lenguaje de alto nivel
- Por lo tanto, hay que aceptar que RISC y CISC nunca tuvieron definiciones claras y precisas y describirlas con un WP:NPOV en lugar de intentar inventar la Única Definición Verdadera.
- KenShirriff ( discusión ) 18:03 24 jun 2023 (UTC) [ responder ]
- Por cierto, tu publicación sobre el 960 hizo referencia a esta secuencia de publicaciones de John Mashey sobre comp.arch, que es algo relevante en este caso. Mashey parece inclinarse por decir que "CISC significa 'no RISC'", y cree que hablar de muchas CPU antiguas como "CISC" o "RISC" no es un ejercicio útil.
- Esa es una secuencia de 1992, de una era anterior a la idea de "arrojar un montón de operaciones simples en un balde y ejecutarlas en forma superescalar y fuera de orden, lo que puede implicar cortar instrucciones complejas en múltiples operaciones simples", por lo que sería interesante ver lo que diría ahora.
- Y las dos ISA CISC que pareció incluir en la categoría de "relativamente simples, en lo que a CISC se refiere", 1) son las dos CISC restantes de ese artículo, 2) tienen un montón de dinero detrás (procesadores x86 para PC y mainframes IBM), y 3) ahora parecen tener implementaciones en el campo de "arrojar un montón de operaciones simples en una canasta y...". Guy Harris ( discusión ) 22:53, 2 julio 2023 (UTC) [ responder ]
He estado pensando que tendría sentido fusionar la página de CISC con la de RISC. El problema es que las páginas de RISC y CISC tienen muchas superposiciones y cubren en su mayoría la misma historia e información, por lo que son en gran medida redundantes (cuando no son contradictorias). Como dice WP:OVERLAP , "Recuerde que Wikipedia no es un diccionario; no es necesario que haya una entrada separada para cada concepto. Por ejemplo, "inflamable" y "no inflamable" se pueden explicar en un artículo sobre inflamabilidad".
No digo que CISC no sea importante, por supuesto. Pero como CISC se define esencialmente en oposición a RISC, no se puede hablar de uno sin el otro. Creo que combinar las páginas mejoraría ambas. ¿Comentarios? KenShirriff ( discusión ) 20:15 4 dic 2023 (UTC) [ responder ]
