El proyecto Future Systems ( FS ) fue un proyecto de investigación y desarrollo llevado a cabo en IBM a principios de la década de 1970 para desarrollar una línea revolucionaria de productos informáticos, incluidos nuevos modelos de software que simplificarían el desarrollo de software mediante la explotación de hardware moderno y potente .
El sistema de archivos tenía dos componentes clave. El primero era el uso de un sistema de almacenamiento de un solo nivel que permite hacer referencia a los datos almacenados en un almacenamiento secundario, como unidades de disco , dentro de un programa como si fueran datos almacenados en la memoria principal ; las variables en el código podrían apuntar a objetos en el almacenamiento y estos se cargarían invisiblemente en la memoria, eliminando la necesidad de escribir código para el manejo de archivos. El segundo era incluir instrucciones correspondientes a las declaraciones en lenguajes de programación de alto nivel , lo que permitía al sistema ejecutar programas directamente sin la necesidad de un compilador para convertir del lenguaje a código de máquina . Uno podría, por ejemplo, escribir un programa en un editor de texto y la máquina podría ejecutarlo directamente.
Combinar los dos conceptos en un único sistema en un único paso resultó ser una tarea imposible. Los ingenieros señalaron esta preocupación desde el principio, pero la dirección y los líderes del proyecto la ignoraron por muchas razones. El proyecto, que se inició oficialmente en el otoño de 1971, estaba moribundo en 1974 y se canceló formalmente en febrero de 1975. El almacenamiento de un solo nivel se implementó en el System/38 y se trasladó a otros sistemas de la línea de productos después de eso, pero el concepto de una máquina que ejecutara directamente lenguajes de alto nivel nunca apareció en un producto de IBM.
El System/360 se anunció en abril de 1964. Sólo seis meses después, IBM inició un proyecto de estudio sobre las tendencias que se estaban produciendo en el mercado y cómo se debían utilizar 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 reemplazar los numerosos componentes individuales del 360 por un número menor de CI. Esto permitiría construir una máquina más potente por el mismo precio que los modelos existentes. [1]
A mediados de los años 1960, el 360 se había convertido en un gran éxito de ventas. Esto influyó en el diseño de las nuevas máquinas, ya que llevó a la demanda de que las máquinas tuvieran compatibilidad completa con la serie 360. Cuando se anunciaron las máquinas en 1970, ahora conocidas como System/370 , eran esencialmente 360 que usaban circuitos integrados de pequeña escala para la lógica, cantidades mucho mayores de memoria interna y otros cambios relativamente menores. [2] Se agregaron algunas instrucciones nuevas y se limpiaron otras, pero el sistema era en gran parte 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 pedidos mucho menores del 370 en comparación con la rápida aceptación del 360 cinco años antes. [4] Por primera vez en décadas, el crecimiento de IBM se estancó. Mientras que algunos en la empresa comenzaron a esforzarse por introducir mejoras útiles en el 370 lo antes posible para hacerlo más atractivo, otros pensaban que nada menos que una reinvención completa del sistema funcionaría a largo plazo. [3]
Dos meses antes del anuncio de los 370, la compañía comenzó a considerar nuevamente los cambios en el mercado y cómo eso influiría en los diseños futuros. [3] En 1965, Gordon Moore predijo que los circuitos integrados verí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 treinta veces en los próximos cinco años y otras treinta veces en los cinco siguientes. Si IBM quería mantener sus cifras de ventas, tendría que vender treinta veces más memoria en cinco años y novecientas veces más cinco años después. De manera similar, se esperaba que el costo del disco duro se redujera diez veces en los próximos diez años. Para mantener su crecimiento tradicional del 15% interanual, en 1980 tendrían que estar vendiendo cuarenta veces más espacio en disco y 3600 veces más memoria. [4]
En cuanto a la computadora en sí, si uno siguiera la progresión del 360 al 370 y luego a un hipotético System/380, las nuevas máquinas se basarían en una integración a gran escala y se reducirían drásticamente en complejidad y costo. No había manera de que pudieran vender una máquina así a su precio actual; si lo intentaban, 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 infrautilizando sus sistemas existentes. Para proporcionar un argumento razonable para comprar una nueva máquina de alta gama, IBM tuvo que encontrar razones para que sus clientes necesitaran esta potencia adicional. [5] [6]
Otra cuestión estratégica era que, mientras que el coste de la informática iba disminuyendo de forma constante, los costes de programación y operaciones, que se componían de costes de personal, iban aumentando de forma constante. Por 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 ella la base de ingresos de IBM. Era imperativo que IBM, al abordar el coste del desarrollo de aplicaciones y las operaciones en sus futuros productos, redujera al mismo tiempo el coste total de TI para los clientes y captara una parte mayor de ese coste. [6]
En 1969, Bob O. Evans , presidente de la división de desarrollo de sistemas de IBM, que desarrolló sus mainframes más grandes , le pidió a Erich Bloch, del laboratorio de IBM en Poughkeepsie, que considerara cómo la empresa podría utilizar estos componentes mucho más baratos para construir máquinas que aún así conservaran los beneficios de la empresa. Bloch, a su vez, le pidió a Carl Conti que esbozara dichos sistemas. Tras ver que se utilizaba el término "sistemas futuros", Evans se refirió al grupo como Advanced Future Systems. El grupo se reunía aproximadamente cada dos semanas.
Entre los muchos desarrollos estudiados inicialmente bajo AFS, un concepto se destacó. En ese momento, estaban surgiendo los primeros sistemas con memoria virtual (VM), y el proyecto seminal Multics había ampliado este concepto como base para un almacenamiento de un solo nivel . En este concepto, todos los datos en el sistema se tratan como si estuvieran en la memoria principal , y si los datos están ubicados físicamente en el almacenamiento secundario , el sistema VM los carga automáticamente en la memoria cuando un programa lo solicita. En lugar de escribir código para leer y escribir datos en archivos, el programador simplemente le decía al sistema operativo que estaría usando 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 aseguraría de que los datos se sincronizaran con el almacenamiento cuando fuera necesario. [7]
Esto fue visto como un concepto particularmente útil en ese momento, ya que la aparición de la memoria de burbuja sugirió 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 uno podría simplemente referirse 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 se cargaron o no. [7]
Evans también le pidió a John McPherson, de la sede de IBM en Armonk , que presidiera otro grupo para estudiar cómo IBM ofrecería estos nuevos diseños en sus numerosas divisiones. Un grupo de doce participantes repartidos en tres divisiones elaboró el "Informe del sistema de nivel superior", o HLS, 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 cara que el hardware. Si un sistema podía reducir en gran medida el coste de desarrollo, entonces ese sistema podría venderse por más dinero, ya que el coste total de operación seguiría siendo inferior al de la competencia. [8]
El concepto básico de la serie System/360 era que se definiría una arquitectura de conjunto de instrucciones (ISA) única que ofreciera todas las instrucciones posibles que pudiera desear un programador en lenguaje ensamblador . Mientras que los sistemas anteriores podían estar dedicados a la programación científica o a los cálculos monetarios y tenían instrucciones para ese tipo de datos, el 360 ofrecía instrucciones para ambas tareas y prácticamente para cualquier otra. Luego se diseñaron máquinas individuales que apuntaban a cargas de trabajo específicas y ejecutaban esas instrucciones directamente en el hardware e implementaban las demás en microcódigo . Esto significaba que cualquier máquina de la familia 360 podía ejecutar programas de cualquier otra, solo que más rápido o más lento según la tarea. Esto resultó ser un enorme éxito, ya que un cliente podía comprar una máquina de gama baja y siempre actualizarla a una más rápida en el futuro, sabiendo que todas sus aplicaciones seguirían funcionando.
Aunque el conjunto de instrucciones del 360 era grande, esas instrucciones eran de bajo nivel y representaban operaciones individuales que la unidad central de procesamiento (CPU) realizaría, como "sumar dos números" o "comparar este número con cero". Los lenguajes de programación y sus vínculos con el sistema operativo permitían a los usuarios escribir programas utilizando conceptos de alto nivel como "abrir archivo" o "sumar estas matrices". Los compiladores convertían estas abstracciones de alto nivel en una serie de instrucciones de código de máquina .
En el caso de HLS, las instrucciones representarían directamente esas tareas de nivel superior. Es decir, habría instrucciones en el código de máquina para "abrir archivo". Si un programa llamaba a esta instrucción, no era necesario convertirla en código de nivel inferior; la máquina lo haría internamente en microcódigo o incluso en una implementación directa en hardware. [8] Esto funcionaba de la mano con el almacenamiento de un solo nivel; para implementar HLS, cada bit de datos del sistema se emparejaba con un descriptor , un registro que contenía el tipo de fecha, su ubicación en la memoria y su precisión y tamaño. Como los descriptores también podían apuntar a matrices y estructuras de registros, esto permitía que el lenguaje de máquina los procesara como objetos atómicos. [8]
Al representar estos objetos de nivel mucho más alto directamente en el sistema, los programas de usuario serían mucho más pequeños y simples. Por ejemplo, para sumar dos matrices de números almacenados en archivos en lenguajes tradicionales, uno generalmente abriría los dos archivos, leería un elemento de cada uno, los sumaría y luego almacenaría el valor en un tercer archivo. En el enfoque HLS, uno simplemente abriría los archivos y llamaría a add. El sistema operativo subyacente los mapearía en la memoria, crearía descriptores que mostraran que ambos son matrices y luego la instrucción add vería que eran matrices y sumaría todos los valores. Asignar ese valor a una matriz recién creada tendría el efecto de volver a escribirlo en el almacenamiento. Un programa que podría ocupar una página o más de código ahora se reducía a unas pocas líneas. Además, como este era el lenguaje natural de la máquina, el shell de comandos era programable de la misma manera, no habría necesidad de "escribir un programa" para una tarea simple como esta, podría ingresarse como un comando. [8]
El informe concluyó:
Tanto el usuario como IBM deberían beneficiarse sustancialmente de la codificación y depuración más sencillas de programas concisos. Esperamos reducir drásticamente el costo de programación y el tamaño de los programas complejos, ya que tanto la calidad del programa como la productividad del programador se verán mejoradas. [8]
Hasta finales de los años 1960, IBM había obtenido la mayor parte de sus beneficios del hardware, ofreciendo software y servicios de soporte junto con sus sistemas para hacerlos más atractivos. Sólo el hardware tenía un precio, pero esos precios incluían una partida 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 posible base para recuperar el coste del software y los servicios. IBM respondió negándose a dar servicio a las máquinas con estos complementos de terceros, lo que dio lugar casi inmediatamente a amplias investigaciones antimonopolio y a muchos recursos legales posteriores. En 1969, la empresa se vio obligada a poner fin a sus acuerdos de agrupación y anunció que vendería productos de software por separado. [9]
Gene Amdahl vio una oportunidad de vender máquinas compatibles sin software; el cliente podía comprar una máquina a Amdahl y el sistema operativo y el resto del software a IBM. Si IBM se negaba a vendérselo, estaría incumpliendo sus obligaciones legales. A principios de 1970, Amdahl abandonó IBM y anunció su intención de introducir máquinas compatibles con el System/370 que serían más rápidas que las ofertas de gama alta de IBM, pero costarían menos de comprar y de operar. [10]
Al principio, IBM no se preocupó. La mayor parte de su dinero se lo ganaban con el software y el soporte técnico, y ese dinero seguiría yendo a parar a sus manos. Pero, para estar seguros, a principios de 1971 se formó un grupo de trabajo interno de IBM, el Proyecto Counterpoint, para estudiar el concepto. Llegaron a la conclusión de que el negocio de mainframes compatibles era realmente 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 crearon en la empresa el deseo de encontrar alguna solución que obligara de nuevo a los clientes a comprar todo a IBM, pero de una manera que no violara las leyes antimonopolio. [7]
Si IBM hubiera seguido las sugerencias del informe HLS, esto significaría que otros proveedores tendrían que copiar el microcódigo que implementaba la enorme cantidad de instrucciones. Como se trataba de software, si lo hicieran, esas compañías estarían sujetas a violaciones de derechos de autor. [7] En ese momento, los conceptos AFS/HLS ganaron nueva vigencia dentro de la empresa.
En mayo-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 ordenadores que aprovechara las ventajas tecnológicas de IBM para dejar obsoletos todos los ordenadores anteriores, tanto los compatibles como los propios productos de IBM. El grupo de trabajo concluyó que valía la pena seguir adelante con el proyecto, pero que la clave para su aceptación en el mercado era una reducción de un orden de magnitud en los costes de desarrollo, funcionamiento y mantenimiento del software de aplicación.
Los principales objetivos del proyecto FS quedaron enunciados de la siguiente manera:
Se esperaba que una nueva arquitectura que hiciera un uso más intensivo de los recursos de hardware, cuyo coste estaba disminuyendo, pudiera simplificar significativamente el desarrollo de software y reducir los costos tanto para IBM como para los clientes.
Un principio de diseño de FS fue un " almacenamiento de un solo nivel " que extendió la idea de memoria virtual (VM) para cubrir datos persistentes. En los diseños tradicionales, los programas asignan memoria para almacenar valores que representan datos. Estos datos normalmente desaparecerían si se apaga la máquina o el usuario cierra la sesión. Para tener estos datos disponibles en el futuro, se necesita código adicional para escribirlos en un almacenamiento permanente como un disco duro y luego leerlos nuevamente en el futuro. Para facilitar estas operaciones comunes, surgieron varios motores de base de datos en la década de 1960 que permitían a los programas entregar datos al motor, que luego los guardaría y los recuperaría nuevamente a pedido.
Otra tecnología emergente en esa época fue el concepto de memoria virtual. En los primeros sistemas, la cantidad de memoria disponible para que un programa asignara datos estaba limitada por la cantidad de memoria principal del sistema, que podía variar en función de factores como el traslado de la misma de una máquina a otra o si otros programas estaban asignando memoria por su cuenta. Los sistemas de memoria virtual abordaron este problema definiendo una cantidad máxima de memoria disponible para todos los programas, normalmente una cantidad muy grande, mucho mayor que la memoria física de la máquina. En el caso de que un programa pida 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 vuelve a cargar de forma invisible 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 VM escriben memoria en un disco de forma invisible, lo que es la misma tarea que el sistema de archivos, por lo que no hay ninguna razón por la que no pueda utilizarse como sistema de archivos. En lugar de que los programas asignen memoria desde la "memoria principal" que luego la VM quizás envíe a algún otro almacenamiento de respaldo , la VM asigna inmediatamente toda la memoria. Esto significa que no es necesario guardar y cargar datos, simplemente asignarlos en la memoria tendrá ese efecto a medida que el sistema VM los escribe. Cuando el usuario vuelve a iniciar sesión, esos datos y los programas que los estaban ejecutando, ya que también están en la misma memoria unificada, están disponibles de inmediato en el mismo estado en el que estaban antes. Se elimina todo el concepto de cargar y guardar, los programas y sistemas completos continúan donde estaban incluso después de reiniciar la máquina.
Este concepto se había explorado en el sistema Multics , pero resultó ser muy lento, pero ese era 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 , en particular la memoria de burbuja , [7] que funcionaba a velocidades similares al núcleo pero tenía una densidad de memoria similar a un disco duro, parecía que un almacenamiento de un solo nivel ya no tendría ningún inconveniente en el rendimiento.
Future Systems tenía previsto convertir el almacenamiento de un solo nivel en el concepto clave de sus nuevos sistemas operativos. En lugar de tener un motor de base de datos independiente al que los programadores pudieran llamar, simplemente habría llamadas en la interfaz de programación de aplicaciones (API) del sistema para recuperar la memoria. Y esas llamadas a la API se basarían en hardware particular o implementaciones de microcódigo , que solo estarían disponibles en los sistemas IBM, logrando así el objetivo de IBM de vincular estrechamente el hardware a los programas que se ejecutaban en él. [7]
Otro principio fue el uso de instrucciones complejas de muy alto nivel para ser implementadas en microcódigo . Como ejemplo, una de las instrucciones, CreateEncapsulatedModule, era un editor de enlaces completo . Otras instrucciones fueron diseñadas para soportar las estructuras de datos internas y las operaciones de lenguajes de programación como FORTRAN , COBOL y PL/I . En efecto, FS fue diseñado para ser el mejor conjunto de instrucciones complejas para computadoras ( CISC ). [7]
Otra forma de presentar el mismo concepto era que toda la colección de funciones previamente implementadas como hardware, software de sistema operativo , software de base de datos y más, ahora se considerarían como conformando un sistema integrado, con cada función elemental implementada en una de las muchas capas que incluyen circuitos, microcódigo y software convencional . Se contemplaban más de una capa de microcódigo y código, a veces denominada picocódigo o milicódigo . Dependiendo de las personas con las que uno estuviera hablando, la noción misma de una "máquina" oscilaba entre aquellas funciones que se implementaban 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 requería un "controlador universal" que se encargara principalmente de las operaciones de entrada y salida fuera del procesador principal. Ese controlador universal tendría un conjunto de instrucciones muy limitado, restringido a las operaciones necesarias para la entrada y salida, lo que supuso un gran avance en el concepto de ordenador con conjunto de instrucciones reducido (RISC).
Mientras tanto, John Cocke , uno de los principales diseñadores de las primeras computadoras IBM, comenzó un proyecto de investigación para diseñar la primera computadora con conjunto de instrucciones reducido ( RISC ). [ cita requerida ] A largo plazo, la arquitectura RISC del IBM 801 , que eventualmente evolucionó hacia las arquitecturas POWER , PowerPC y Power de IBM , demostró ser mucho más barata de implementar y capaz de lograr una velocidad de reloj mucho más alta.
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 paso del tiempo, varios otros proyectos de investigación en varias ubicaciones de IBM se fusionaron con el proyecto FS o se asociaron con él.
Durante toda su vida, el proyecto FS se llevó a cabo bajo estrictas medidas de seguridad. El proyecto se dividió en muchos subproyectos asignados a diferentes equipos. La documentación también se dividió en muchas 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. Se realizó un seguimiento de los documentos y se podía acceder a ellos en cualquier momento.
En el memorando de Sowa (ver enlaces externos a continuación) señaló que el objetivo declarado de toda esta burocracia es evitar que alguien comprenda todo el sistema; este objetivo ciertamente se ha logrado.
Como 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 producir la contribución esperada. Algunos equipos incluso trabajaban en servicios financieros sin saberlo. Esto explica por qué, cuando se les pide que definan los servicios financieros, la mayoría de las personas dan una respuesta muy parcial, limitada a la intersección de los servicios financieros con su campo de competencia.
Se planificaron tres implementaciones de la arquitectura FS: el modelo de gama alta se estaba diseñando en Poughkeepsie, Nueva York , donde se construyeron las computadoras más grandes y rápidas de IBM; el modelo siguiente se estaba diseñando en Endicott, Nueva York , 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]
Se podría ofrecer un rango continuo de rendimiento variando el número de procesadores en un sistema en cada uno de los cuatro niveles de implementación.
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 ASDD de Mohansic (a medio camino entre las oficinas centrales de Armonk/White Plains y Poughkeepsie).
El proyecto FS se dio por finalizado en 1975. Las razones que se dieron para dar por finalizado el proyecto dependen de la persona a la que se le preguntó, cada una de las cuales expuso los problemas relacionados con el dominio con el que estaba familiarizada. En realidad, el éxito del proyecto dependía de un gran número de avances en todas las áreas, desde el diseño y la fabricación de circuitos hasta la comercialización y el mantenimiento. Aunque cada uno de los problemas, considerados de forma aislada, podría haberse resuelto, la probabilidad de que todos pudieran resolverse a tiempo y de formas mutuamente compatibles era prácticamente nula.
Un síntoma de ello fue el pobre rendimiento de su mayor implementación, pero el proyecto también se vio empañado por prolongadas discusiones internas sobre diversos aspectos técnicos, incluyendo debates internos de IBM sobre los méritos 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 no se podía realizar una copia de seguridad parcial del almacenamiento de un solo nivel de todo el sistema, [ aclaración necesaria ] lo que presagiaba la partición del almacenamiento de un solo nivel del System/38 por parte del IBM AS/400. [13] [ aclaración necesaria ] Además, las simulaciones mostraron que la ejecución de las instrucciones nativas del FS en la máquina de gama alta era más lenta que la del emulador del System/370 en la misma máquina. [14]
El proyecto FS se dio por finalizado cuando IBM se dio cuenta de que la aceptación de los clientes sería mucho más limitada de lo previsto originalmente porque no había una vía razonable de migración de aplicaciones para los clientes de la arquitectura 360. Para dejar la máxima libertad para diseñar un sistema verdaderamente revolucionario, la facilidad de migración de aplicaciones no era uno de los objetivos de diseño principales del proyecto FS, pero se debía abordar mediante ayudas de migración de software que tomaran la nueva arquitectura como algo dado. Al final, parecía que el coste de migrar la masa de inversiones de los usuarios en aplicaciones basadas en COBOL y lenguaje ensamblador a FS era, en muchos casos, probablemente mayor que el coste de adquirir un nuevo sistema.
Aunque el proyecto FS en su conjunto se dio por terminado, en Rochester se siguió desarrollando una versión simplificada de la arquitectura para la más pequeña de las tres máquinas. Finalmente se lanzó como IBM System/38 , que demostró ser un buen diseño para facilitar la programación, pero que tenía una potencia lamentablemente insuficiente. El AS/400 heredó la misma arquitectura, pero con mejoras de rendimiento. En ambas máquinas, el conjunto de instrucciones de alto nivel generado por los compiladores no se interpreta, sino que se traduce a un conjunto de instrucciones de máquina de nivel inferior y se ejecuta; el conjunto de instrucciones de nivel inferior original era un conjunto de instrucciones CISC con algunas similitudes con el conjunto de instrucciones System/360 . [15] En máquinas posteriores, el conjunto de instrucciones de nivel inferior era una versión extendida del conjunto de instrucciones PowerPC , que evolucionó a partir de la máquina RISC de John Cocke. La plataforma de hardware dedicada fue reemplazada en 2008 por la plataforma IBM Power Systems que ejecuta el sistema operativo IBM i .
Además de System/38 y AS/400, que heredaron gran parte de la arquitectura FS, se incorporaron fragmentos de la tecnología de Future Systems en las siguientes partes de la línea de productos de IBM: