El proyecto Future Systems ( FS ) fue un proyecto de investigación y desarrollo emprendido 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 .
Había dos componentes clave para FS. El primero fue el uso de un almacén 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 almacenados y se cargarían de manera invisible 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 , permitiendo al sistema ejecutar programas directamente sin necesidad de un compilador para convertir el lenguaje a código de máquina . Por ejemplo, se podría escribir un programa en un editor de texto y la máquina podría ejecutarlo directamente.
Combinar los dos conceptos en un solo sistema en un solo paso resultó ser una tarea imposible, algo que los ingenieros señalaron desde el principio, pero que la gerencia y los líderes del proyecto ignoraron por muchas razones. Comenzó oficialmente en el otoño de 1971, en 1974 el proyecto estaba moribundo y se canceló formalmente en febrero de 1975. La tienda de un solo nivel se implementó en el System/38 y luego se trasladó a otros sistemas de la gama, pero el concepto de un La máquina que ejecutaba directamente lenguajes de alto nivel no aparecía en la línea de IBM.
El System/360 se anunció en abril de 1964. Sólo seis meses después, IBM inició un proyecto de estudio sobre qué tendencias se estaban produciendo en el mercado y cómo debían utilizarse en una serie de máquinas que sustituirían a la 360 en el futuro. Un cambio significativo fue la introducción de circuitos integrados (CI) útiles, que permitirían reemplazar muchos componentes individuales del 360 por una cantidad 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 la década de 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 exigió que las máquinas tuvieran total compatibilidad 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 medida 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 más pequeños para el 370 en comparación con la rápida adopción del 360 cinco años antes. [4] Por primera vez en décadas, el crecimiento de IBM se estancó. Si bien algunos miembros de la empresa comenzaron a esforzarse por introducir mejoras útiles en el 370 lo antes posible para hacerlo más atractivo, otros sintieron 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 una vez más comenzó a considerar 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 el número de circuitos que soportaban, hoy conocido como 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 iba a llegar a cero más rápido de lo que podía medirse. [3]
Un estudio interno del Comité de Tecnología Corporativa (CTC) concluyó que se produciría una reducción de 30 veces en el precio de la memoria en los próximos cinco años, y de otras 30 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 del disco duro se redujera diez veces en los próximos diez años. Para mantener su tradicional crecimiento interanual del 15%, en 1980 tendrían que vender 40 veces más espacio en disco y 3.600 veces más memoria. [4]
En términos de la computadora en sí, si uno siguiera la progresión del 360 al 370 y hasta algún hipotético Sistema/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 de este tipo al precio actual; si lo intentaran, otra empresa introduciría sistemas mucho menos costosos. [3] En cambio, podrían producir máquinas mucho más potentes al mismo precio, 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 el costo de la informática disminuía constantemente, los costos de programación y operaciones, compuestos de costos de personal, aumentaban constantemente. 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 de aplicaciones y las operaciones en sus productos futuros, al mismo tiempo redujera el costo total de TI para los clientes y capturara una porción mayor de ese costo. [6]
En 1969, Bob O. Evans , presidente de la División de Desarrollo de Sistemas de IBM, que desarrolló sus mainframes más grandes , pidió a Erich Bloch del IBM Poughkeepsie Lab que considerara cómo la empresa podría utilizar estos componentes mucho más baratos para construir máquinas que aún conservarían las ganancias de la empresa. . Bloch, a su vez, pidió a Carl Conti que describiera dichos sistemas. Habiendo visto que se utilizaba el término "sistemas futuros", Evans se refirió al grupo como Sistemas Futuros Avanzados. El grupo se reunía aproximadamente cada dos semanas.
Entre los muchos avances estudiados inicialmente en el marco de AFS, destacó un concepto. En aquel momento estaban surgiendo los primeros sistemas con memoria virtual (VM), y el proyecto fundamental Multics había ampliado este concepto como base para un almacén 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 están ubicados físicamente en un almacenamiento secundario , el sistema VM los carga automáticamente en la memoria cuando un programa los solicita. En lugar de escribir código para leer y escribir datos en archivos, el programador simplemente le decía al sistema operativo que usarí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 garantizaría que los datos se sincronizaran con el almacenamiento cuando fuera necesario. [7]
Esto se vio 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 almacenamiento separado no tenía sentido, y tener punteros en una sola memoria grande no solo significaría que uno podría simplemente referirse a cualquier datos como si fueran locales, pero también elimina 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 pidió a John McPherson que presidiera un grupo similar en la sede de IBM en Armonk para presidir otro grupo que considerara cómo IBM ofrecería estos nuevos diseños en sus numerosas divisiones. Un grupo de doce participantes repartidos en tres divisiones produjo el "Informe del sistema de nivel superior", o HLS, que se entregó el 25 de febrero de 1970. Un componente clave de HLS fue la idea de que la programación era más cara que el hardware. Si un sistema pudiera reducir en gran medida el costo de desarrollo, entonces ese sistema podría venderse por más dinero, ya que el costo total de operación seguiría siendo menor que el de la competencia. [8]
El concepto básico de la serie System/360 era que se definiría una arquitectura de conjunto de instrucciones única (ISA) que ofreciera todas las instrucciones posibles que el programador en lenguaje ensamblador pudiera desear. Mientras que los sistemas anteriores podían estar dedicados a la programación científica o cálculos monetarios y tenían instrucciones para ese tipo de datos, el 360 ofrecía instrucciones para prácticamente todas las tareas. Luego se diseñaron máquinas individuales que se enfocaban en tareas particulares 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, sólo que más rápido o más lento según la tarea. Esto resultó enormemente exitoso, 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 ejecutándose.
Aunque el conjunto de instrucciones del 360 era grande, esas instrucciones todavía eran de bajo nivel y representaban operaciones únicas que realizaría la unidad central de procesamiento (CPU), 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 permitieron a los usuarios escribir programas utilizando conceptos de alto nivel como "abrir archivo" o "agregar estas matrices". Los compiladores convertirían estas abstracciones de nivel superior en una serie de instrucciones de código de máquina .
Para 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 llamara a esta instrucción, no había necesidad de convertirla en código de nivel inferior, la máquina lo haría internamente en microcódigo o incluso en una implementación directa de hardware. [8] Esto funcionó de la mano con la tienda de un solo nivel; Para implementar HLS, cada bit de datos en el sistema se emparejó 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 permitió 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 conjuntos de números contenidos en archivos en idiomas tradicionales, generalmente se abrirían los dos archivos, se leería un elemento de cada uno, se agregarían y luego se almacenaría el valor en un tercer archivo. En el enfoque HLS, uno simplemente abriría los archivos y llamaría a agregar. El sistema operativo subyacente los asignaría a la memoria, crearía descriptores que mostraran que ambos son matrices y luego la instrucción de agregar 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 podía ocupar una página de código ahora se reducía a unas pocas líneas. Además, como éste 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 sencilla de programas concisos. Esperamos reducir drásticamente el costo de la programación y el tamaño de los programas complejos, a medida que mejoren tanto la calidad del programa como la productividad del programador. [8]
Hasta finales de la década de 1960, IBM había estado obteniendo la mayor parte de sus ganancias del hardware, agrupando 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 asignación para software y servicios. [7]
Otros fabricantes habían comenzado a comercializar hardware compatible, principalmente periféricos como unidades de cinta y de 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 condujo casi de inmediato a amplias investigaciones antimonopolio y a muchos recursos legales posteriores. En 1969, la empresa se vio obligada a poner fin a sus acuerdos de venta por paquetes y anunció que vendería productos de software por separado.
Gene Amdahl vio la oportunidad de vender máquinas compatibles sin software; el cliente podía comprar una máquina de Amdahl y el sistema operativo y otro software de IBM. Si IBM se negara a vendérselo, estarían incumpliendo sus obligaciones legales. En 1970, Amdahl renunció a IBM y anunció su intención de introducir máquinas compatibles con System/370 que serían más rápidas que las ofertas de gama alta de IBM pero que costarían menos de comprar y operar.
A principios de 1971, un grupo de trabajo interno de IBM, el Proyecto Contrapunto, concluyó que el negocio de mainframes compatibles era efectivamente viable y que la base para cobrar por el software y los servicios como parte del precio del hardware desaparecería rápidamente. Estos eventos crearon un deseo dentro de la empresa de encontrar alguna solución que una vez más obligara a los clientes a comprar todo a IBM, pero de una manera que no violara las leyes antimonopolio. [7]
Si IBM siguiera las sugerencias del informe HLS, esto significaría que otros proveedores tendrían que copiar el microcódigo que implementa la gran cantidad de instrucciones. Como se trataba de software, si lo hicieran, esas empresas estarían sujetas a violaciones de derechos de autor. [7] En este punto, 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: ofertas compatibles pero también productos propios de IBM. El grupo de trabajo concluyó que valía la pena continuar con el proyecto, pero que la clave para la aceptación en el mercado era una reducción de orden de magnitud en los costos de desarrollo, operación y mantenimiento de software de aplicación.
En consecuencia, los principales objetivos del proyecto FS se establecieron como sigue:
Se esperaba que una nueva arquitectura que hiciera un uso más intensivo de los recursos de hardware, cuyo costo estaba bajando, 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 era un " almacenamiento de un solo nivel " que extendía 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 la máquina se apaga 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 volver a leerlos en el futuro. Para facilitar estas operaciones comunes, en la década de 1960 surgieron varios motores de bases de datos que permitían a los programas entregar datos al motor, que luego los guardaba y recuperaba nuevamente según demanda.
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 a los datos estaba limitada por la cantidad de memoria principal del sistema, que podía variar en función de factores como si se movía de una máquina a otra, o si se ejecutaban otros programas. asignando memoria propia. 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 más que la memoria física de la máquina. En el caso de que un programa solicite 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 carga nuevamente de manera invisible en la memoria principal. [9]
Un almacén 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 de forma invisible en un disco, que es la misma tarea que el sistema de archivos, por lo que no hay razón para que no se pueda utilizar como sistema de archivos. En lugar de que los programas asignen memoria desde la "memoria principal", que luego quizás la VM envíe a algún otro almacén de respaldo , la VM asigna inmediatamente toda la memoria. Esto significa que no es necesario guardar ni cargar datos; simplemente asignarlos en la memoria tendrá ese efecto a medida que el sistema VM los escriba. 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 inmediatamente disponibles en el mismo estado 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 fue un efecto secundario del hardware disponible donde la memoria principal se implementó en el núcleo con un almacén 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 a las del núcleo pero tenía una densidad de memoria similar a la de un disco duro, parecía que un almacenamiento de un solo nivel ya no tendría ningún rendimiento. Abajo.
Future Systems tenía previsto convertir la tienda de un solo nivel en el concepto clave de sus nuevos sistemas operativos. En lugar de tener un motor de base de datos separado al que los programadores llamarían, simplemente habría llamadas en la interfaz de programación de aplicaciones (API) del sistema para recuperar memoria. Y esas llamadas API se basarían en implementaciones particulares de hardware o microcódigo , que sólo estarían disponibles en los sistemas IBM, logrando así el objetivo de IBM de vincular estrechamente el hardware a los programas que se ejecutan en él. [7]
Otro principio fue el uso de instrucciones complejas de muy alto nivel para implementarlas en microcódigo . A modo de ejemplo, una de las instrucciones, CreateEncapsulatedModuleera un editor de enlaces completo. Otras instrucciones fueron diseñadas para soportar las estructuras de datos internas y operaciones de lenguajes de programación como FORTRAN , COBOL y PL/I . De hecho, FS fue diseñado para ser la computadora con conjunto de instrucciones complejas ( CISC ) definitiva. [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ía como un sistema integrado, con todas y cada una de las funciones elementales implementadas en una de muchas. capas que incluyen circuitos, microcódigo y software convencional . Se contemplaron más de una capa de microcódigo y código, a veces denominado picocódigo o milicode . Dependiendo de las personas con las que se hablaba, la noción misma de "máquina" oscilaba, por tanto, 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 especialistas en hardware). arquitectos de sistemas).
El diseño general también requería un "controlador universal" para manejar principalmente operaciones de entrada y salida fuera del procesador principal. Ese controlador universal tendría un conjunto de instrucciones muy limitado, restringido a aquellas operaciones requeridas para E/S, siendo pionero en el concepto de computadora con conjunto de instrucciones reducido (RISC).
Mientras tanto, John Cocke , uno de los principales diseñadores de las primeras computadoras de IBM, inició un proyecto de investigación para diseñar la primera computadora con conjunto de instrucciones reducido ( RISC ). [ cita necesaria ] A largo plazo, la arquitectura IBM 801 RISC, que eventualmente evolucionó hacia las arquitecturas POWER , PowerPC y Power de IBM , demostró ser mucho más barata de implementar y capaz de alcanzar velocidades de reloj mucho más altas.
El proyecto IBM Future Systems (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 ubicaciones de IBM se fusionaron en el proyecto FS. o se asoció con él.
Durante toda su vida, el proyecto FS se llevó a cabo bajo estrictas disposiciones 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 saberlo por parte de la oficina del proyecto. Los documentos eran rastreados y podían recuperarse en cualquier momento.
En el memorando de Sowa (ver Enlaces externos, más abajo) 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 estaban trabajando en FS sin saberlo. Esto explica por qué, cuando se les pide que definan los FS, la mayoría de las personas dan una respuesta muy parcial, limitada a la intersección de los FS con su campo de competencia.
Se planearon 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 siguiente modelo se estaba diseñando en Endicott, Nueva York , que era responsable de las computadoras de gama media; el modelo a continuación se estaba diseñando en Böblingen, Alemania , y el modelo más pequeño se estaba diseñando en Hursley, Reino Unido . [10]
Se podría ofrecer una gama continua 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 de Mohansic ASDD (a medio camino entre la sede de Armonk/White Plains y Poughkeepsie).
El proyecto FS fue cancelado en 1975. Las razones dadas para cancelar el proyecto dependen de la persona a la que se le preguntó, cada uno de los cuales plantea las cuestiones relacionadas con el dominio que conocía. En realidad, el éxito del proyecto dependía de una gran cantidad de avances en todas las áreas, desde el diseño y la fabricación de circuitos hasta el marketing y el mantenimiento. Aunque cada cuestión aislada podría haberse resuelto, la probabilidad de que todas pudieran resolverse a tiempo y de manera mutuamente compatible era prácticamente nula.
Un síntoma fue el pobre desempeño de su implementación más grande, pero el proyecto también se vio empañado por prolongadas discusiones internas sobre varios aspectos técnicos, incluidos debates internos de IBM sobre los méritos de los diseños RISC versus CISC. La complejidad del conjunto de instrucciones fue otro obstáculo; Los propios ingenieros de IBM lo consideraron "incomprensible" y hubo fuertes indicios de que no se podía realizar una copia de seguridad parcial del almacén de un solo nivel de todo el sistema, [ se necesita aclaración ] prediciendo la partición del IBM AS/400 del sistema de un solo nivel del System/38. almacenar. [11] [ se necesita aclaración ] 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. [12]
El proyecto FS finalmente terminó cuando IBM se dio cuenta de que la aceptación del cliente sería mucho más limitada de lo previsto originalmente porque no había una ruta razonable de migración de aplicaciones para los clientes de 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 principales objetivos de diseño del proyecto FS, sino que debía abordarse mediante ayudas para la migración de software tomando la nueva arquitectura como un hecho. Al final, parecía que el costo de migrar la gran cantidad de inversiones de los usuarios en COBOL y aplicaciones basadas en lenguaje ensamblador a FS era en muchos casos probablemente mayor que el costo de adquirir un nuevo sistema.
Aunque el proyecto FS en su conjunto fue cancelado, en Rochester se continuó desarrollando una versión simplificada de la arquitectura para la más pequeña de las tres máquinas. Finalmente fue lanzado como IBM System/38 , que demostró ser un buen diseño para facilitar la programación, pero lamentablemente tenía poca potencia. 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 . [13] 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 del System/38 y el AS/400, que heredaron gran parte de la arquitectura FS, se incorporaron fragmentos de tecnología Future Systems en las siguientes partes de la línea de productos de IBM: