stringtranslate.com

IBM 801

El 801 fue un diseño de unidad central de procesamiento (CPU) experimental 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 las muchas variantes de modos de direccionamiento que se encuentran en los diseños CISC . Desarrollado originalmente como procesador para un conmutador telefónico , más tarde se utilizó como base para una minicomputadora y varios productos para su línea de mainframe . El diseño inicial fue un procesador de 24 bits ; que pronto fue reemplazado por implementaciones de 32 bits de los mismos conceptos y el 801 original de 24 bits se usó solo hasta principios de la década de 1980.

El 801 fue extremadamente influyente en el mercado de las computadoras. [ cita necesaria ] Armado con enormes cantidades de datos de rendimiento, IBM pudo demostrar que el diseño simple podía 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 el de mayor tamaño. Instrucciones CISC optimizadas. La aplicación de estas mismas técnicas incluso a procesadores existentes como el System/370 generalmente también duplicó el rendimiento de esos sistemas. 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 Ciencias en 1994.

Historia

Concepto original

En 1974, IBM comenzó a examinar la posibilidad de construir un conmutador telefónico capaz de atender 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 cuando se agregaron los gastos generales de tiempo y otras consideraciones, dicha máquina requería un rendimiento de aproximadamente 12 MIPS. [1] Esto requeriría un avance significativo en el rendimiento; su máquina actual de primera línea, la IBM System/370 Modelo 168 de finales de 1972, ofrecía alrededor de 3 MIPS. [2]

El grupo que trabaja en este proyecto en el Centro de Investigación Thomas J. Watson , entre el que se encuentra John Cocke , diseñó un procesador para este fin. Para alcanzar el rendimiento requerido, consideraron el tipo de operaciones que requería dicha máquina y eliminaron las que no eran apropiadas. Esto llevó, por ejemplo, a eliminar una unidad de punto flotante , que no sería necesaria en esta aplicación. Más importante aún, también eliminaron muchas de las instrucciones que funcionaban con los datos de la memoria principal y dejaron solo aquellas instrucciones que funcionaban con los registros internos del procesador , ya que eran mucho más rápidos de usar y el código simple en un interruptor telefónico se podía escribir para su uso. Sólo 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 se canceló en 1975, pero el equipo había logrado avances considerables en el concepto y en octubre IBM decidió continuarlo como un diseño de propósito general. Sin un proyecto obvio al que adjuntarlo, el equipo decidió llamarlo "801" por el edificio en el que trabajaban. Para la función 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 realizar sólo cinco instrucciones: cargar valor desde la memoria, almacenar valor en la memoria, bifurcar , comparar números de punto fijo y sumar números de punto fijo. Esto sugirió que el mismo diseño de procesador simplificado funcionaría tan bien para una minicomputadora de uso general como para un conmutador de propósito especial. [3]

Justificación contra el uso de microcódigo

Esta conclusión iba en contra del diseño de procesadores contemporáneo, que se basaba en el concepto de uso de microcódigo . IBM estuvo entre 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 y todos 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ó a los clientes sentirse 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 los diseñadores habían utilizado 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 permitía al programador seleccionar la instrucción exacta. variación que necesitaban para cualquier tarea en particular. El procesador leería esa instrucción y usaría un microcódigo para dividirla en una serie de instrucciones internas. Por ejemplo, se podría implementar la suma de dos números en la memoria cargando esos dos números en registros, sumándolos y luego almacenando la suma 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 pasó a conocerse como conjunto de instrucciones ortogonales .

El equipo 801 notó un efecto secundario de este concepto; Cuando se enfrentan a la gran cantidad de versiones posibles de una instrucción determinada, los autores del compilador normalmente eligen una única versión. Normalmente, este era el que se implementaba en el hardware de las máquinas de gama baja. Eso aseguró 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 podrí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 ignoraron 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 realización clave del proyecto 801:

Imponer microcódigo entre una computadora y sus usuarios impone una costosa sobrecarga al realizar las instrucciones ejecutadas con mayor frecuencia. [3]

El microcódigo tarda un tiempo distinto de cero en examinar la instrucción antes de ejecutarla. 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 esencialmente ejecutaba pequeñas subrutinas dedicadas a una implementación de hardware particular, en última instancia realizaba la misma tarea básica que el compilador: implementar instrucciones de nivel superior como una secuencia de instrucciones específicas de la máquina. Simplemente eliminar el microcódigo e implementarlo en el compilador podría dar como resultado una máquina más rápida. [3]

Una preocupación era que los programas escritos para una máquina así ocuparían más memoria; algunas tareas que podrían realizarse con una sola instrucción en el 370 tendrían que expresarse como instrucciones múltiples en el 801. Por ejemplo, sumar dos números de la memoria requeriría dos instrucciones de carga para registrar, una de adición de registro a registro y luego un almacenamiento en memoria. Potencialmente, esto podría ralentizar el sistema en general si tuviera que dedicar más tiempo a leer instrucciones de la memoria que antes a 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 tener aproximadamente la misma longitud que los escritos para el 370. [5]

Primeras implementaciones

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, por lo que las instrucciones generalmente tenían 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 MECL-10K de Motorola [8] en grandes placas personalizadas envueltas en cables. La CPU tenía una frecuencia de 66 ciclos ns (aproximadamente 15,15 MHz) y podía calcular a una velocidad rápida de aproximadamente 15  MIPS .

La arquitectura 801 se utilizó en una variedad de dispositivos IBM, incluidos controladores de canal para sus mainframes S/370 (como el IBM 3090 ), [9] : 377  varios dispositivos de red y como unidad de ejecución de microcódigo vertical en los modelos 9373 y 9375. Procesadores 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 IBM ROMP [9] : 378  utilizado en la estación de trabajo IBM RT PC y en varias computadoras experimentales de IBM Research . Un derivado de la arquitectura 801 con direccionamiento de 32 bits llamado Iliad estaba destinado a servir como procesador principal del fallido proyecto del sistema de rango medio Fort Knox . [12]

Modificaciones posteriores

Habiendo sido diseñado originalmente para un sistema de funciones limitadas, el diseño 801 carecía de una serie de características que se ven en máquinas más grandes. Entre ellos, destacaba la falta de soporte de hardware para la 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, la compatibilidad con el hardware era una característica imprescindible. Además, en la década de 1980 el mundo de la informática en su conjunto avanzaba hacia sistemas de 32 bits y existía el deseo de hacer lo mismo con el 801. [13]

Pasar 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 utilizar en el código matemático típico. Idealmente, ambos operandos de entrada permanecerían en registros donde podrían reutilizarse en operaciones posteriores. En el formato de dos operandos, uno de los dos valores se sobrescribía con el resultado y, a menudo, uno de los valores tenía que volver a cargarse desde la memoria. Al pasar 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 tales 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 ampliación de las palabras de instrucción de 24 a 32 bits, los programas no crecieron el correspondiente 33% debido a las cargas y guardados evitados debido a estos dos cambios. [13]

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

Cuando la nueva versión del 801 se ejecutó 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 el código de máquina 370 usando el Compilador PL/I del 370 . [14] Cuando portaron su lenguaje experimental "PL.8" al 370 y compilaron aplicaciones usándolo, esas aplicaciones se ejecutaron hasta tres veces más rápido que las versiones PL/I. Esto se debió a que el compilador tomó decisiones similares a las de RISC sobre cómo el código generado usa los registros del procesador, optimizando así tantos accesos a la memoria como sea posible. Estos eran tan caros en el 370 como en el 801, pero este costo normalmente estaba oculto por la simplicidad de una sola línea de código CISC. El compilador PL.8 fue mucho más agresivo a la hora de evitar cargas y guardados, lo que resultó en un mayor rendimiento incluso en un procesador CISC. [14]

Los proyectos Cheetah, Panther y America

A principios de la década de 1980, las lecciones aprendidas en el 801 se combinaron con las del proyecto IBM Advanced Computer Systems , lo que dio como resultado un procesador experimental llamado "Cheetah". Cheetah era un procesador superescalar de 2 vías , que evolucionó hasta convertirse 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 recupera 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ó hasta convertirlo en el sistema IBM RS/6000 . El RS/6000 funcionando a 25 MHz fue una de las máquinas más rápidas de su época. Superó a otras máquinas RISC entre dos y 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 801 que pudiera fabricarse de manera eficiente a varias escalas. El resultado fue la arquitectura del conjunto de instrucciones IBM POWER y la rama PowerPC .

Reconocimiento

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

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

Referencias

Citas

  1. ^ ab Cocke y Markstein 1990, pág. 4.
  2. ^ Savard, John. "En el 370/165 y el 360/85".
  3. ^ abcde Cocke y Markstein 1990, pág. 5.
  4. ^ Sack, Harald (7 de abril de 2016). El IBM System/360 y el uso del microcódigo. McGraw-Hill. ISBN 978-0-07-050686-2. {{cite book}}: |website=ignorado ( ayuda )
  5. ^ Cocke y Markstein 1990, págs. 6–7.
  6. ^ "La minicomputadora 801: descripción general" (PDF) . 8 de octubre de 1976. p. 9.
  7. ^ "Principios de funcionamiento del sistema 801" (PDF) . 16 de enero de 1976.
  8. ^ Radin 1982.
  9. ^ ab Dewar, Robert BK; Smosna, Mateo (1990). Microprocesadores: la visión de un programador . McGraw-Hill.
  10. ^ ab Cocke y Markstein 1990, pág. 9.
  11. ^ Mitchell, James (septiembre de 1988). "Implementación de una arquitectura mainframe en un procesador 9370". Boletín ACM SIGMICRO . 19 (3): 3–10. doi :10.1145/62185.62186. ISSN  1050-916X. S2CID  14602753.
  12. ^ Frank G. Soltis (1997). Dentro del AS/400, segunda edición. Prensa de Duque. ISBN 978-1882419661.
  13. ^ abc Cocke y Markstein 1990, pag. 7.
  14. ^ ab Cocke y Markstein 1990, pág. 8.
  15. ^ Smotherman, Mark (2005). "Encuesta de procesadores superescalares". Diseño de procesadores modernos: fundamentos de los procesadores superescalares . Por Shen, Juan Pablo; Lipasti, Mikko H. McGraw-Hill.
  16. ^ "John Cocke". premios.acm.org . Consultado el 29 de agosto de 2022 .
  17. ^ "John Cocke - Premio AM Turing". amturing.acm.org . Consultado el 29 de agosto de 2022 .
  18. ^ "Premio Mujeres Pioneras en Computación ENIAC de la IEEE Computer Society". 9 de abril de 2018 . Consultado el 29 de agosto de 2022 .
  19. ^ ab "NSTMF". NSTMF . Consultado el 12 de mayo de 2020 .
  20. ^ "Destinatarios de la medalla IEEE John von Neumann" (PDF) . Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) .
  21. ^ "John Cocke". El Instituto Franklin . 2014-01-10 . Consultado el 29 de agosto de 2022 .
  22. ^ Flynn, Michael J. (1995). "Arquitectura informática: diseño de procesadores canalizados y paralelos" . Aprendizaje de Jones y Bartlett. págs. 54–56. ISBN 0867202041.

Bibliografía

Otras lecturas

enlaces externos