IBM 801

El 801 fue un diseño experimental de unidad central de procesamiento (CPU) desarrollado por IBM durante la década de 1970. Se considera el primer diseño RISC moderno , que se basa en registros de procesador para todos los cálculos y elimina los muchos modos de direccionamiento variantes que se encuentran en los diseños CISC . Originalmente desarrollado como procesador para un conmutador telefónico , se utilizó más tarde como base para una minicomputadora y una serie de productos para su línea de mainframes . El diseño inicial era un procesador de 24 bits ; pronto fue reemplazado por implementaciones de 32 bits de los mismos conceptos y el 801 original de 24 bits se utilizó solo hasta principios de la década de 1980.

El 801 tuvo una gran influencia en el mercado de las computadoras. ^{[ cita requerida ]} Con enormes cantidades de datos de rendimiento, IBM pudo demostrar que el diseño simple era capaz de superar fácilmente incluso a los diseños de CPU clásicos más potentes, al mismo tiempo que producía un código de máquina que era solo marginalmente más grande que las instrucciones CISC altamente optimizadas. La aplicación de estas mismas técnicas incluso a procesadores existentes como el System/370 generalmente duplicaba el rendimiento de esos sistemas también. Esto demostró el valor del concepto RISC, y todos los sistemas futuros de IBM se basaron en los principios desarrollados durante el proyecto 801.

Por su trabajo en el 801, John Cocke fue reconocido con varios premios y medallas, incluido el Premio Turing en 1987, la Medalla Nacional de Tecnología en 1991 y la Medalla Nacional de Ciencia en 1994.

En 1974, IBM comenzó a estudiar la posibilidad de construir una centralita telefónica capaz de gestionar un millón de llamadas por hora, o unas 300 llamadas por segundo. Calcularon que cada llamada requeriría 20.000 instrucciones para completarse y, si se añadían los costes de tiempo y otras consideraciones, una máquina de estas características requería un rendimiento de unos 12 MIPS. ^[1] Esto exigiría un avance significativo en el rendimiento; su máquina de gama alta actual, el IBM System/370 Modelo 168 de finales de 1972, ofrecía unos 3 MIPS. ^[2]

El grupo que trabajaba en este proyecto en el Centro de Investigación Thomas J. Watson , incluido John Cocke , diseñó un procesador para este propósito. Para alcanzar el rendimiento requerido, consideraron el tipo de operaciones que requería una máquina de este tipo y eliminaron las que no eran apropiadas. Esto llevó a la eliminación de una unidad de punto flotante , por ejemplo, que no sería necesaria en esta aplicación. Más críticamente, también eliminaron muchas de las instrucciones que trabajaban con datos en la memoria principal y dejaron solo aquellas instrucciones que trabajaban en los registros internos del procesador , ya que estos eran mucho más rápidos de usar y el código simple en un conmutador telefónico podía escribirse para usar solo este tipo de instrucciones. El resultado de este trabajo fue un diseño conceptual para un procesador simplificado con el rendimiento requerido. ^[1]

El proyecto del conmutador telefónico fue cancelado en 1975, pero el equipo había logrado un progreso considerable en el concepto y en octubre IBM decidió continuarlo como un diseño de propósito general. Sin un proyecto obvio al que vincularlo, el equipo decidió llamarlo "801" en honor al edificio en el que trabajaban. Para el rol de propósito general, el equipo comenzó a considerar programas del mundo real que se ejecutarían en una minicomputadora típica . IBM había recopilado enormes cantidades de datos estadísticos sobre el rendimiento de cargas de trabajo del mundo real en sus máquinas y estos datos demostraron que más de la mitad del tiempo en un programa típico se dedicaba a ejecutar solo cinco instrucciones: cargar valor de la memoria, almacenar valor en la memoria, bifurcar, comparar números de punto fijo y agregar números de punto fijo. Esto sugería que el mismo diseño de procesador simplificado funcionaría tan bien para una minicomputadora de propósito general como para un conmutador de propósito especial. ^[3]

Esta conclusión iba en contra del diseño de procesadores contemporáneos, que se basaba en el concepto de uso de microcódigo . IBM había sido uno de los primeros en hacer un uso generalizado de esta técnica como parte de su serie System/360 . Los 360 y 370 venían en una variedad de niveles de rendimiento que ejecutaban el mismo código de lenguaje de máquina . En las máquinas de gama alta, muchas de estas instrucciones se implementaban directamente en el hardware, como una unidad de punto flotante, mientras que las máquinas de gama baja podían simular esas instrucciones utilizando una secuencia de otras instrucciones codificadas en microcódigo. Esto permitió que una única interfaz binaria de aplicación se ejecutara en toda la línea y permitió que los clientes se sintieran seguros de que si alguna vez necesitaban más rendimiento, podrían pasar a una máquina más rápida sin ningún otro cambio. ^[4]

El microcódigo permitió que un procesador simple ofreciera muchas instrucciones, que habían sido utilizadas por los diseñadores para implementar una amplia variedad de modos de direccionamiento . Por ejemplo, una instrucción como ADDpodría tener una docena de versiones, una que suma dos números en registros internos, una que suma un registro a un valor en la memoria, una que suma dos valores de la memoria, etc. Esto permitió al programador seleccionar la variación exacta que necesitaba para cualquier tarea en particular. El procesador leería esa instrucción y usaría microcódigo para dividirla en una serie de instrucciones internas. Por ejemplo, sumar dos números en la memoria podría implementarse cargando esos dos números en registros, sumándolos y luego almacenando la suma nuevamente en la memoria. ^[3] La idea de ofrecer todos los modos de direccionamiento posibles para todas las instrucciones se convirtió en un objetivo de los diseñadores de procesadores, y el concepto se conoció como un conjunto de instrucciones ortogonales .

El equipo 801 se dio cuenta de un efecto secundario de este concepto: cuando se enfrentaban a la plétora de versiones posibles de una instrucción dada, los autores de compiladores normalmente elegían una única versión. Esta era típicamente la que se implementaba en hardware en las máquinas de gama baja. Eso aseguraba que el código de máquina generado por el compilador se ejecutara lo más rápido posible en toda la línea. Si bien el uso de otras versiones de instrucciones podía ejecutarse incluso más rápido en una máquina que las implementara en hardware, la complejidad de saber cuál elegir en una lista de máquinas en constante cambio hacía que esto fuera extremadamente poco atractivo, y los autores de compiladores ignoraban en gran medida estas posibilidades. ^[3]

Como resultado, la mayoría de las instrucciones disponibles en el conjunto de instrucciones nunca se utilizaron en programas compilados. Y fue aquí donde el equipo realizó la conclusión clave del proyecto 801:

La imposición de microcódigo entre una computadora y sus usuarios supone una sobrecarga costosa a la hora de ejecutar las instrucciones que se ejecutan con mayor frecuencia. ^[3]

El microcódigo tarda un tiempo distinto de cero en examinar la instrucción antes de que se ejecute. El mismo procesador subyacente sin el microcódigo eliminaría esta sobrecarga y ejecutaría esas instrucciones más rápido. Dado que el microcódigo ejecutaba esencialmente pequeñas subrutinas dedicadas a una implementación de hardware particular, en última instancia estaba realizando la misma tarea básica que el compilador, implementando instrucciones de nivel superior como una secuencia de instrucciones específicas de la máquina. Simplemente eliminando el microcódigo e implementándolo en el compilador podría resultar en una máquina más rápida. ^[3]

Una de las preocupaciones era que los programas escritos para una máquina de este tipo ocuparían más memoria; algunas tareas que podían realizarse con una sola instrucción en el 370 tendrían que expresarse como múltiples instrucciones en el 801. Por ejemplo, sumar dos números de la memoria requeriría dos instrucciones de carga a registro, una suma de registro a registro y luego una de almacenamiento a memoria. Esto podría ralentizar potencialmente el sistema en general si tuviera que dedicar más tiempo a leer instrucciones de la memoria del que antes se necesitaba para decodificarlas. A medida que continuaron trabajando en el diseño y mejoraron sus compiladores, descubrieron que la longitud total del programa seguía disminuyendo, hasta llegar a ser aproximadamente la misma que la de los escritos para el 370. ^[5]

La arquitectura propuesta inicialmente era una máquina con dieciséis registros de 24 bits y sin memoria virtual . ^{[6] [7]} Utilizaba un formato de dos operandos en la instrucción, de modo que las instrucciones eran generalmente de la forma A = A + B, a diferencia del formato de tres operandos, A = B + C. La CPU resultante estuvo operativa en el verano de 1980 y se implementó utilizando la tecnología de componentes discretos Motorola MECL-10K ^[8] en grandes placas personalizadas con envoltura de cables. La CPU tenía una frecuencia de reloj de 66 ns (aproximadamente 15,15 MHz) y podía calcular a la rápida velocidad de aproximadamente 15  MIPS .

La arquitectura 801 se utilizó en una variedad de dispositivos IBM, incluidos los controladores de canal para sus mainframes S/370 (como el IBM 3090 ), ^{[9] : 377} varios dispositivos de red y como una unidad de ejecución de microcódigo vertical en los procesadores 9373 y 9375 de la familia de mainframes IBM 9370. ^{[10] [11]} La versión original de la arquitectura 801 fue la base para la arquitectura del microprocesador ROMP de IBM ^{[9] : 378} utilizado en la computadora de estación de trabajo IBM RT PC y varias computadoras experimentales de IBM Research . Un derivado de la arquitectura 801 con direccionamiento de 32 bits llamado Iliad estaba destinado a servir como el procesador principal del fallido proyecto de sistema de rango medio Fort Knox . ^[12]

Al haber sido diseñado originalmente para un sistema de funciones limitadas, el diseño del 801 carecía de una serie de características que se veían en máquinas más grandes. Entre ellas, destacaba la falta de soporte de hardware para memoria virtual , que no era necesaria para la función de controlador y se había implementado en el software de los primeros sistemas 801 que la necesitaban. Para un uso más generalizado, el soporte de hardware era una característica imprescindible. Además, en la década de 1980, el mundo de la informática en su conjunto se estaba moviendo hacia sistemas de 32 bits , y existía el deseo de hacer lo mismo con el 801. ^[13]

El cambio a un formato de 32 bits tuvo otra ventaja significativa. En la práctica, se descubrió que el formato de dos operandos era difícil de usar en el código matemático típico. Lo ideal sería que ambos operandos de entrada permanecieran en registros donde pudieran reutilizarse en operaciones posteriores. En el formato de dos operandos, uno de los dos valores se sobrescribía con el resultado y, a menudo, era necesario volver a cargar uno de los valores desde la memoria. Al cambiar a un formato de 32 bits, los bits adicionales en las palabras de instrucción permitieron especificar un registro adicional, de modo que la salida de dichas operaciones pudiera dirigirse a un registro separado. La palabra de instrucción más grande también permitió aumentar el número de registros de dieciséis a treinta y dos, un cambio que había sido obvio al examinar el código 801. A pesar de la expansión de las palabras de instrucción de 24 a 32 bits, los programas no crecieron en el 33% correspondiente debido a las cargas y los guardados evitados debido a estos dos cambios. ^[13]

Otras adiciones deseables incluyen instrucciones para trabajar con datos de cadena que fueron codificados en formato "empaquetado" con varios caracteres en una sola palabra de memoria, y adiciones para trabajar con decimales codificados en binario , incluyendo un sumador que podría transportar números decimales de cuatro bits. ^[13]

Cuando se ejecutó la nueva versión del 801 como simulador en el 370, el equipo se sorprendió al descubrir que el código compilado en el 801 y ejecutado en el simulador a menudo se ejecutaba más rápido que el mismo código fuente compilado directamente en código de máquina del 370 utilizando el compilador PL/I del 370. ^[14] Cuando trasladaron su lenguaje experimental "PL.8" al 370 y compilaron aplicaciones utilizándolo, esas aplicaciones se ejecutaban hasta tres veces más rápido que las versiones PL/I. Esto se debía a que el compilador tomaba decisiones similares a las de RISC sobre cómo el código generado utiliza los registros del procesador, optimizando así tantos accesos a la memoria como fuera posible. Estos eran tan caros en el 370 como en el 801, pero este costo normalmente quedaba oculto por la simplicidad de una sola línea de código CISC. El compilador PL.8 era mucho más agresivo a la hora de evitar cargas y guardados, lo que daba como resultado un mayor rendimiento incluso en un procesador CISC. ^[14]

A principios de los años 1980, las lecciones aprendidas en el 801 se combinaron con las del proyecto IBM Advanced Computer Systems , dando como resultado un procesador experimental llamado "Cheetah". Cheetah era un procesador superescalar de 2 vías , que evolucionó en un procesador llamado "Panther" en 1985, y finalmente en un diseño superescalar de 4 vías llamado "America" ​​en 1986. ^[15] Este era un conjunto de procesadores de tres chips que incluía un procesador de instrucciones que busca y decodifica instrucciones, un procesador de punto fijo que comparte funciones con el procesador de instrucciones y un procesador de punto flotante para aquellos sistemas que lo requieren. Diseñado por el equipo 801, el diseño final se envió a la oficina de IBM en Austin en 1986, donde se desarrolló en el sistema IBM RS/6000 . El RS/6000 que funcionaba a 25 MHz fue una de las máquinas más rápidas de su época. Superó a otras máquinas RISC dos o tres veces en pruebas comunes, y superó fácilmente a los sistemas CISC más antiguos. ^[10]

Después del RS/6000, la empresa centró su atención en una versión de los conceptos del 801 que pudiera fabricarse de manera eficiente en diversas escalas. El resultado fue la arquitectura del conjunto de instrucciones IBM POWER y el derivado PowerPC .

Por su trabajo en el 801, John Cocke recibió varios premios y medallas:

• 1985: Premio Eckert-Mauchly ^[16]
• 1987: Premio AM Turing ^[17]
• 1989: Premio al pionero informático ^[18]
• 1991: Medalla Nacional de Tecnología ^[19]
• 1994: Medalla IEEE John von Neumann ^[20]
• 1994: Medalla Nacional de Ciencias ^[19]
• 2000: Medalla Benjamin Franklin (Instituto Franklin) ^[21]

Michael J. Flynn considera al 801 como el primer RISC. ^[22]

• Cocke, John; Markstein, Victoria (enero de 1990). "La evolución de la tecnología RISC en IBM" (PDF) . IBM Journal of Research and Development . 34 (1): 4–11. doi :10.1147/rd.341.0004.
• Cocke, John (marzo de 1988). "La búsqueda de rendimiento en procesadores científicos". Conferencias de la ACM sobre el premio Turing . Vol. 31. p. 252. doi : 10.1145/1283920.1283945 . ISBN . 978-1-4503-1049-9.
• Radin, G. (1982). "El miniordenador 801". Actas del primer simposio internacional sobre soporte arquitectónico para lenguajes de programación y sistemas operativos . ASPLOS -I. págs. 39–47. doi :10.1145/800050.801824. ISBN 0-89791-066-4.

• "Los investigadores de IBM sugieren que modificar la arquitectura de los ordenadores es una forma de aumentar el rendimiento". Electronics . Vol. 49, núm. 25. 23 de diciembre de 1976. pp. 0–31.
• McLellan, V. (octubre de 1979). "IBM Mini: un cambio radical". Datamation . Vol. 25, núm. 11. págs. 53–55.
• Dewar, Robert BK; Smosna, Matthew (1990). Microprocesadores: la perspectiva de un programador . McGraw-Hill. págs. 258–264.
• Tabak, Daniel (1987). Arquitectura RISC . Research Studies Press. págs. 69–72.

• La minicomputadora 801: una descripción general
• Principios de funcionamiento del IBM System 801, versión 2
• Definición del subsistema de E/S 801
• Archivos de IBM: Una breve historia de RISC, IBM RS/6000 y IBM eServer pSeries en Wayback Machine (archivado el 3 de mayo de 2006)