Proyecto de sistemas futuros de IBM

El System/360 se anunció en abril de 1964. Tan solo seis meses después, IBM inició un proyecto de estudio sobre las tendencias del mercado y cómo aprovecharlas en una serie de máquinas que reemplazarían al 360 en el futuro. Un cambio significativo fue la introducción de circuitos integrados (CI) útiles, que permitirían sustituir los numerosos componentes individuales del 360 por un menor número de CI. Esto posibilitaría la creación de una máquina más potente al mismo precio que los modelos existentes. ^{[ 1 ]}

A mediados de la década de 1960, la 360 se había convertido en un éxito de ventas masivo. Esto influyó en el diseño de las nuevas máquinas, ya que generó la exigencia de que tuvieran compatibilidad total con la serie 360. Cuando se anunciaron las máquinas en 1970, ahora conocidas como System/370 , eran esencialmente 360 ​​que utilizaban circuitos integrados de pequeña escala para la lógica, mucha más memoria interna y otros cambios relativamente menores. ^{[ 2 ]} Se agregaron algunas instrucciones nuevas y se mejoraron otras, pero el sistema era prácticamente idéntico desde el punto de vista del programador. ^{[ 3 ]}

La recesión de 1969-1970 provocó una desaceleración de las ventas en el período 1970-71 y una disminución considerable de los pedidos del modelo 370 en comparación con la rápida adopción del modelo 360 cinco años antes. ^{[ 4 ]} Por primera vez en décadas, el crecimiento de IBM se estancó. Mientras que algunos en la compañía comenzaron a realizar mejoras útiles en el modelo 370 lo antes posible para hacerlo más atractivo, otros consideraban que solo una reinvención completa del sistema sería viable a largo plazo. ^{[ 3 ]}

Dos meses antes del anuncio de los 370, la compañía volvió a considerar los cambios en el mercado y cómo estos influirían en los diseños futuros. ^{[ 3 ]} En 1965, Gordon Moore predijo que los circuitos integrados experimentarían un crecimiento exponencial en la cantidad de circuitos que soportaban, lo que hoy se conoce como la Ley de Moore . Jerrier A. Haddad, de IBM, escribió un memorando sobre el tema, sugiriendo que el costo de la lógica y la memoria se reduciría a cero más rápido de lo que se podía medir. ^{[ 3 ]}

Un estudio interno del Comité de Tecnología Corporativa (CTC) concluyó que el precio de la memoria se reduciría 30 veces en los próximos cinco años, y otras 30 veces en los cinco siguientes. Si IBM quería mantener sus cifras de ventas, tendría que vender 30 veces más memoria en cinco años, y 900 veces más cinco años después. De manera similar, se esperaba que el costo de los discos duros disminuyera diez veces en los próximos diez años. Para mantener su crecimiento tradicional del 15% anual, para 1980 tendrían que vender 40 veces más espacio en disco y 3600 veces más memoria. ^{[ 4 ]}

En cuanto al ordenador en sí, si se siguiera la progresión del 360 al 370 y a un hipotético System/380, las nuevas máquinas se basarían en la integración a gran escala y su complejidad y coste se reducirían drásticamente. No había forma de que pudieran vender una máquina así a sus precios actuales; si lo intentaran, otra compañía lanzaría sistemas mucho más económicos. ^{[ 3 ]} En cambio, podrían producir máquinas mucho más potentes a los mismos precios, pero sus clientes ya estaban subutilizando sus sistemas existentes. Para justificar la compra de una nueva máquina de gama alta, IBM tuvo que encontrar razones para que sus clientes necesitaran esa potencia adicional. ^{[ 5 ] [ 6 ]}

Otro problema estratégico era que, si bien el costo de la computación disminuía constantemente, los costos de programación y operación, al estar compuestos por costos de personal, aumentaban de manera constante. Por lo tanto, la parte del presupuesto de TI del cliente disponible para los proveedores de hardware se reduciría significativamente en los próximos años, y con ello la base de ingresos de IBM. Era imperativo que IBM, al abordar el costo del desarrollo y la operación de aplicaciones en sus futuros productos, redujera simultáneamente el costo total de TI para los clientes y captara una mayor parte de ese costo. ^{[ 6 ]}

En 1969, Bob O. Evans , presidente de la División de Desarrollo de Sistemas de IBM, responsable del desarrollo de sus mainframes más grandes , solicitó a Erich Bloch, del Laboratorio IBM de Poughkeepsie, que estudiara cómo la compañía podría utilizar estos componentes, mucho más económicos, para construir máquinas que mantuvieran la rentabilidad. Bloch, a su vez, pidió a Carl Conti que describiera dichos sistemas. Tras haber visto el término "sistemas del futuro", Evans denominó al grupo Sistemas Avanzados del Futuro. El grupo se reunía aproximadamente cada dos semanas.

Entre los numerosos desarrollos estudiados inicialmente bajo AFS, un concepto destacó. En aquel entonces, surgían los primeros sistemas con memoria virtual (VM), y el proyecto Multics, pionero en este campo , había desarrollado este concepto como base para un almacenamiento de un solo nivel . En este concepto, todos los datos del sistema se tratan como si estuvieran en la memoria principal , y si los datos se encuentran físicamente en el almacenamiento secundario , el sistema VM los carga automáticamente en la memoria cuando un programa los requiere. En lugar de escribir código para leer y escribir datos en archivos, el programador simplemente le indicaba al sistema operativo que utilizaría ciertos datos, que luego aparecían como objetos en la memoria del programa y podían manipularse como cualquier otra variable . El sistema VM se encargaba de que los datos estuvieran sincronizados con el almacenamiento cuando fuera necesario. ^{[ 7 ]}

En aquel momento, este concepto se consideró particularmente útil, ya que la aparición de la memoria de burbuja sugería que los sistemas futuros no tendrían memoria central y unidades de disco separadas , sino que todo se almacenaría en una gran cantidad de memoria de burbuja. ^{[ 7 ]} Físicamente, los sistemas serían almacenes de un solo nivel, por lo que la idea de tener otra capa para "archivos" que representara un almacenamiento separado no tenía sentido, y tener punteros a una única memoria grande no solo significaría que se podría simplemente hacer referencia a cualquier dato como si fuera local, sino que también eliminaría la necesidad de interfaces de programación de aplicaciones (API) separadas para los mismos datos dependiendo de si estaban cargados o no. ^{[ 7 ]}

Evans también le pidió a John McPherson, de la sede de IBM en Armonk, que presidiera otro grupo para analizar cómo IBM ofrecería estos nuevos diseños en sus diversas divisiones. Un grupo de doce participantes, distribuidos en tres divisiones, elaboró ​​el "Informe del Sistema de Nivel Superior" (HLS, por sus siglas en inglés), que se entregó el 25 de febrero de 1970. Un componente clave del HLS era la idea de que la programación era más costosa que el hardware. Si un sistema podía reducir considerablemente el costo de desarrollo, entonces podría venderse a un precio mayor, ya que el costo operativo total seguiría siendo inferior al de la competencia. ^{[ 8 ]}

El concepto básico de la serie System/360 era definir una arquitectura de conjunto de instrucciones (ISA) única que ofreciera todas las instrucciones posibles que un programador de lenguaje ensamblador pudiera desear. Mientras que los sistemas anteriores se dedicaban a la programación científica o a cálculos monetarios y contaban con instrucciones para ese tipo de datos, el 360 ofrecía instrucciones para ambas tareas y prácticamente cualquier otra. Posteriormente, se diseñaron máquinas individuales orientadas a cargas de trabajo específicas, ejecutando esas instrucciones directamente en hardware e implementando las demás en microcódigo . Esto significaba que cualquier máquina de la familia 360 podía ejecutar programas de cualquier otra, aunque a mayor o menor velocidad según la tarea. Esto resultó enormemente exitoso, ya que un cliente podía comprar una máquina de gama baja y actualizarla a una más rápida en el futuro, con la seguridad de que todas sus aplicaciones seguirían funcionando.

Aunque el conjunto de instrucciones de la Xbox 360 era extenso, estas seguían siendo de bajo nivel, representando operaciones individuales que la unidad central de procesamiento (CPU) realizaba, como "sumar dos números" o "comparar este número con cero". Los lenguajes de programación y su conexión con el sistema operativo permitían a los usuarios escribir programas utilizando conceptos de alto nivel como "abrir archivo" o "sumar estos arreglos". Los compiladores convertían estas abstracciones de alto nivel en una serie de instrucciones de código máquina .

Para HLS, las instrucciones representarían directamente esas tareas de nivel superior. Es decir, habría instrucciones en el código máquina para "abrir archivo". Si un programa llamaba a esta instrucción, no era necesario convertirla a código de nivel inferior; la máquina lo haría internamente en microcódigo o incluso mediante una implementación directa de hardware. ^{[ 8 ]} Esto funcionaba en conjunto con el almacenamiento de un solo nivel; para implementar HLS, cada bit de datos en el sistema se asociaba con un descriptor , un registro que contenía el tipo de datos, su ubicación en memoria, su precisión y su tamaño. Como los descriptores también podían apuntar a matrices y estructuras de registros, esto permitía al lenguaje máquina procesarlos como objetos atómicos. ^{[ 8 ]}

Al representar estos objetos de nivel superior directamente en el sistema, los programas de usuario serían mucho más pequeños y sencillos. Por ejemplo, para sumar dos matrices de números almacenadas en archivos en lenguajes tradicionales, normalmente se abrirían los dos archivos, se leería un elemento de cada uno, se sumarían y luego se almacenaría el valor en un tercer archivo. Con el enfoque HLS, simplemente se abrirían los archivos y se llamaría a la función `add`. El sistema operativo subyacente los mapearía en memoria, crearía descriptores que los mostrarían como matrices y, a continuación, la instrucción `add` detectaría que se trata de matrices y sumaría todos los valores. Asignar ese valor a una matriz recién creada tendría el efecto de escribirlo de nuevo en el almacenamiento. Un programa que podría ocupar una página de código se reducía ahora a unas pocas líneas. Además, como este era el lenguaje natural de la máquina, el intérprete de comandos era programable de la misma manera; no habría necesidad de "escribir un programa" para una tarea tan sencilla, sino que podría introducirse como un comando. ^{[ 8 ]}

El informe concluyó:

Tanto el usuario como IBM se beneficiarán sustancialmente de la mayor facilidad para codificar y depurar programas concisos. Prevemos una reducción drástica del coste de programación y del tamaño de los programas complejos, ya que se mejorará tanto la calidad del programa como la productividad del programador. ^{[ 8 ]}

Hasta finales de la década de 1960, IBM había obtenido la mayor parte de sus ganancias del hardware, incluyendo software y servicios de soporte junto con sus sistemas para hacerlos más atractivos. Solo el hardware tenía un precio, pero estos precios incluían una asignación para software y servicios. ^{[ 7 ]}

Otros fabricantes habían comenzado a comercializar hardware compatible, principalmente periféricos como unidades de cinta y disco , a un precio significativamente inferior al de IBM, reduciendo así la base posible para recuperar el costo del software y los servicios. IBM respondió negándose a dar servicio a las máquinas con estos complementos de terceros, lo que provocó casi de inmediato amplias investigaciones antimonopolio y numerosas acciones legales posteriores. En 1969, la empresa se vio obligada a poner fin a sus acuerdos de empaquetado y anunció que vendería los productos de software por separado. ^{[ 9 ]}

Gene Amdahl vio una oportunidad para vender máquinas compatibles sin software; el cliente podía comprar una máquina a Amdahl y el sistema operativo y demás software a IBM. Si IBM se negaba a vendérselo, estaría incumpliendo sus obligaciones legales. A principios de 1970, Amdahl dejó IBM y anunció su intención de lanzar máquinas compatibles con System/370 que serían más rápidas que las ofertas de gama alta de IBM, pero con un menor coste de compra y funcionamiento. ^{[ 10 ]}

Al principio, IBM no se mostró preocupada. La mayor parte de sus ingresos provenían del software y el soporte, y ese dinero seguiría yendo a parar a sus manos. Sin embargo, a principios de 1971 se formó un grupo de trabajo interno de IBM, el Proyecto Counterpoint, para estudiar el concepto. Concluyeron que el negocio de los mainframes compatibles era viable y que la base para cobrar por el software y los servicios como parte del precio del hardware desaparecería rápidamente. Estos acontecimientos generaron en la empresa el deseo de encontrar una solución que obligara nuevamente a los clientes a comprar todo a IBM, pero de una manera que no infringiera las leyes antimonopolio. ^{[ 7 ]}

Si IBM hubiera seguido las sugerencias del informe HLS, otros proveedores habrían tenido que copiar el microcódigo que implementaba la gran cantidad de instrucciones. Dado que se trataba de software, de hacerlo, dichas empresas estarían sujetas a infracciones de derechos de autor. ^{[ 7 ]} En este punto, los conceptos de AFS/HLS cobraron nueva relevancia dentro de la empresa.

Entre mayo y junio de 1971, un grupo de trabajo internacional se reunió en Armonk bajo la dirección de John Opel , entonces vicepresidente de IBM. Su misión era investigar la viabilidad de una nueva línea de computadoras que aprovechara las ventajas tecnológicas de IBM para dejar obsoletas todas las computadoras anteriores, tanto las compatibles como los propios productos de IBM. El grupo de trabajo concluyó que el proyecto merecía la pena, pero que la clave para su aceptación en el mercado residía en una reducción drástica de los costos de desarrollo, operación y mantenimiento del software de aplicación.

En consecuencia, los principales objetivos del proyecto FS se enunciaron de la siguiente manera:

• dejar obsoletos todos los equipos informáticos existentes, incluidos los de IBM, mediante la explotación total de las tecnologías más recientes,
• disminuir en gran medida los costos y esfuerzos involucrados en el desarrollo y operación de aplicaciones,
• Proporcionar una base técnicamente sólida para la reagrupación de la mayor cantidad posible de las ofertas de IBM (hardware, software y servicios).

Se esperaba que una nueva arquitectura que hiciera un mayor uso de los recursos de hardware, cuyo coste estaba disminuyendo, pudiera simplificar significativamente el desarrollo de software y reducir los costes tanto para IBM como para sus clientes.

Uno de los principios de diseño de FS fue el " almacenamiento de un solo nivel ", que extendió el concepto de memoria virtual (VM) para abarcar los datos persistentes. En los diseños tradicionales, los programas asignan memoria para almacenar valores que representan datos. Estos datos normalmente desaparecen si se apaga el equipo o el usuario cierra sesión. Para que estos datos estén disponibles en el futuro, se necesita código adicional para escribirlos en un almacenamiento permanente, como un disco duro , y luego recuperarlos. Para facilitar estas operaciones comunes, en la década de 1960 surgieron varios motores de bases de datos que permitían a los programas pasar los datos al motor, el cual los guardaba y los recuperaba cuando se necesitaban.

Otra tecnología emergente en ese momento fue el concepto de memoria virtual. En los primeros sistemas, la cantidad de memoria disponible para que un programa la asignara para datos estaba limitada por la cantidad de memoria principal del sistema, que podía variar según factores como su transferencia de una máquina a otra o si otros programas asignaban su propia memoria. Los sistemas de memoria virtual abordaron este problema definiendo una cantidad máxima de memoria disponible para todos los programas, generalmente un número muy grande, mucho mayor que la memoria física de la máquina. Si un programa solicita asignar memoria que no está físicamente disponible, se escribe un bloque de memoria principal en el disco y ese espacio se utiliza para la nueva asignación. Si el programa solicita datos de esa área de memoria descargada ("paginada" o "en cola"), se vuelven a cargar invisiblemente en la memoria principal. ^{[ 11 ]}

Un almacenamiento de un solo nivel es esencialmente una expansión de la memoria virtual a toda la memoria, interna o externa. Los sistemas de memoria virtual escriben la memoria en un disco de forma invisible, lo que equivale a la función del sistema de archivos, por lo que no hay razón para que no pueda utilizarse como tal. En lugar de que los programas asignen memoria desde la "memoria principal", que luego la memoria virtual podría enviar a otro almacenamiento , toda la memoria se asigna inmediatamente por la propia memoria virtual. Esto significa que no es necesario guardar ni cargar datos; simplemente asignarlos en la memoria tendrá ese efecto a medida que el sistema de memoria virtual los escribe. Cuando el usuario vuelve a iniciar sesión, esos datos, y los programas que los estaban ejecutando, ya que también se encuentran en la misma memoria unificada, están disponibles inmediatamente en el mismo estado en que se encontraban antes. Se elimina por completo el concepto de carga y guardado; los programas y sistemas completos retoman su estado anterior incluso después de reiniciar la máquina.

Este concepto se había explorado en el sistema Multics , pero resultó ser muy lento; sin embargo, esto fue un efecto secundario del hardware disponible, donde la memoria principal se implementaba en el núcleo con un almacenamiento de respaldo mucho más lento en forma de disco duro o tambor . Con la introducción de nuevas formas de memoria no volátil , sobre todo la memoria de burbuja , ^{[ 7 ]} que funcionaba a velocidades similares a las del núcleo pero con una densidad de memoria similar a la de un disco duro, parecía que un almacenamiento de un solo nivel ya no tendría ninguna desventaja de rendimiento.

Future Systems planeaba convertir el almacenamiento de un solo nivel en el concepto clave de sus nuevos sistemas operativos. En lugar de contar con un motor de base de datos independiente al que los programadores llamarían, simplemente habría llamadas en la interfaz de programación de aplicaciones (API) del sistema para recuperar la memoria. Estas llamadas a la API se basarían en implementaciones específicas de hardware o microcódigo , disponibles únicamente en sistemas IBM, logrando así el objetivo de IBM de vincular estrechamente el hardware con los programas que se ejecutaban en él. ^{[ 7 ]}

Otro principio fue el uso de instrucciones complejas de muy alto nivel que se implementarían en microcódigo . Por ejemplo, una de las instrucciones CreateEncapsulatedModuleera un editor de enlaces completo. Otras instrucciones se diseñaron para soportar las estructuras de datos internas y las operaciones de lenguajes de programación como FORTRAN , COBOL y PL/I . En efecto, FS se diseñó para ser la computadora con el conjunto de instrucciones complejo definitivo ( CISC ). ^{[ 7 ]}

Otra forma de presentar el mismo concepto era que el conjunto completo de funciones previamente implementadas como hardware, software de sistema operativo , software de base de datos y más, se consideraría ahora como un sistema integrado, con cada función elemental implementada en una de las muchas capas, incluyendo circuitos, microcódigo y software convencional . Se contemplaba más de una capa de microcódigo y código, a veces denominada picocódigo o milicódigo . Dependiendo de con quién se hablara, la noción misma de "máquina" abarcaba desde las funciones implementadas como circuitos (para los especialistas en hardware) hasta el conjunto completo de funciones ofrecidas a los usuarios, independientemente de su implementación (para los arquitectos de sistemas).

El diseño general también contemplaba un "controlador universal" para gestionar principalmente las operaciones de entrada/salida fuera del procesador principal. Dicho controlador universal contaría con un conjunto de instrucciones muy limitado, restringido a las operaciones necesarias para la entrada/salida, sentando las bases del concepto de computadora con conjunto de instrucciones reducido (RISC).

Mientras tanto, John Cocke , uno de los principales diseñadores de las primeras computadoras IBM, inició un proyecto de investigación para diseñar la primera computadora con conjunto de instrucciones reducido ( RISC ). A la larga, la arquitectura RISC IBM 801 , que posteriormente evolucionó hacia las arquitecturas POWER , PowerPC y Power de IBM , demostró ser mucho más económica de implementar y capaz de alcanzar una frecuencia de reloj mucho mayor.

El proyecto FS se inició oficialmente en septiembre de 1971, siguiendo las recomendaciones de un grupo de trabajo especial reunido en el segundo trimestre de 1971. Con el tiempo, varios otros proyectos de investigación en diversas sedes de IBM se fusionaron con el proyecto FS o se asociaron a él.

Durante toda su duración, el proyecto FS se desarrolló bajo estrictas medidas de seguridad. El proyecto se dividió en numerosos subproyectos asignados a diferentes equipos. La documentación también se dividió en múltiples partes, y el acceso a cada documento estaba sujeto a la verificación de la necesidad de conocerlo por parte de la oficina del proyecto. Los documentos se registraban y podían consultarse en cualquier momento.

En el memorándum de Sowa (ver Enlaces externos, más abajo) señaló que el objetivo declarado de toda esta burocracia es impedir que cualquiera entienda todo el sistema; este objetivo ciertamente se ha logrado.

En consecuencia, la mayoría de las personas que trabajaban en el proyecto tenían una visión extremadamente limitada del mismo, restringida a lo que necesitaban saber para aportar lo que se esperaba de ellas. Algunos equipos incluso trabajaban en FS sin tener conocimiento de ello. Esto explica por qué, al pedirles que definan FS, la mayoría de las personas dan una respuesta muy parcial, limitada a la intersección de FS con su campo de competencia.

Se planificaron tres implementaciones de la arquitectura FS: el modelo de gama alta se estaba diseñando en Poughkeepsie, NY , donde se construían las computadoras más grandes y rápidas de IBM; el siguiente modelo se estaba diseñando en Endicott, NY , que era responsable de las computadoras de gama media; el modelo inferior se estaba diseñando en Böblingen, Alemania , y el modelo más pequeño se estaba diseñando en Hursley, Reino Unido . ^{[ 12 ]}

Variando el número de procesadores en cada uno de los cuatro niveles de implementación, se podría ofrecer un rango continuo de rendimiento.

A principios de 1973, la gestión general del proyecto y los equipos responsables de las capas más "externas" comunes a todas las implementaciones se consolidaron en el laboratorio Mohansic ASDD (a medio camino entre la sede de Armonk/White Plains y Poughkeepsie).

El proyecto FS se canceló en 1975. Las razones para su cancelación varían según la persona consultada, quien expone los problemas relacionados con su área de especialización. En realidad, el éxito del proyecto dependía de numerosos avances en todas las áreas, desde el diseño y la fabricación de circuitos hasta la comercialización y el mantenimiento. Si bien cada problema, considerado de forma aislada, podría haberse resuelto, la probabilidad de que todos se resolvieran a tiempo y de manera compatible era prácticamente nula.

Un síntoma fue el bajo rendimiento de su implementación más grande, pero el proyecto también se vio afectado por prolongadas discusiones internas sobre diversos aspectos técnicos, incluyendo debates internos de IBM sobre las ventajas de los diseños RISC frente a los CISC. La complejidad del conjunto de instrucciones fue otro obstáculo; los propios ingenieros de IBM lo consideraban "incomprensible" y había fuertes indicios de que el almacenamiento de un solo nivel del sistema no podía respaldarse parcialmente, lo que presagiaba la partición del almacenamiento de un solo nivel del System/38 por parte del IBM AS/400. ^{[ 13 ]} Además, las simulaciones mostraron que la ejecución de instrucciones FS nativas en la máquina de gama alta era más lenta que la del emulador System/370 en la misma máquina. ^{[ 14 ]}

El proyecto FS se canceló finalmente cuando IBM se percató de que la aceptación por parte de los clientes sería mucho más limitada de lo previsto inicialmente, ya que no existía una ruta de migración de aplicaciones viable para los clientes de la arquitectura 360. Para permitir la máxima libertad en el diseño de un sistema verdaderamente revolucionario, la facilidad de migración de aplicaciones no era uno de los objetivos principales del proyecto FS, sino que se abordaría mediante herramientas de migración de software que partieran de la nueva arquitectura. Al final, resultó que el coste de migrar la gran cantidad de inversiones de los usuarios en aplicaciones basadas en COBOL y lenguaje ensamblador a FS era, en muchos casos, superior al coste de adquirir un nuevo sistema.

• Aspray, Bill (24 de septiembre de 2000). "Historia oral de Gene Amdahl" (PDF) (Entrevista).
• Pugh, Emerson W. (1995). Building IBM: Shaping an Industry and Its Technology . MIT Press. ISBN 0-262-16147-8.
• Pugh, Emerson W.; et  al. (1991). Los sistemas IBM 360 y los primeros 370. MIT Press. ISBN 0-262-16123-0.
• Case, Richard (7 de diciembre de 2006). "Historia oral de Richard Case" (PDF) . Museo de Historia de la Computación (Entrevista). Entrevistado por Burton Grad.