Projet FS - Définition

Les raisons de l'abandon

Les raisons de l'abandon du projet en 1975 sont mal connues. A cause du cloisonnement mis en place pour préserver la sécurité, les raisons invoquées dépendent de l'interlocuteur, qui met en avant les difficultés rencontrées dans le domaine avec lequel il est familier.

Quelques raisons citées sont:

• les performances médiocres comparées à celles des systèmes 370 et compatibles.
• la complexité du jeu d'instructions, qui était jugé "incompréhensible" par de nombreux développeurs d'IBM.
• le coût pour les clients de la migration depuis leurs anciens systèmes. En effet, afin de laisser aux architectes le maximum de liberté pour définir un système vraiment révolutionnaire, la facilité de migration n'avait pas été incluse dans les objectifs initiaux, mais devait être traitée après coup par les aides logicielles.

Vers la fin du projet, il apparaissait que le coût de migration de la masse des investissements des clients dans des applications écrites en assembleur et en COBOL serait souvent supérieur au coût d'acquisition d'un nouveau système. De plus, la modification des habitudes s'avérait telle que la coexistence obligatoire pendant plusieurs années des deux systèmes serait une source de coûts énormes pour le constructeur comme pour ses clients.

En réalité, la réussite du projet nécessitait un grand nombre de percées dans tous les domaines, allant de la conception et de la fabrication des circuits jusqu'au marketing et à la maintenance, en passant par l'architecture et toutes les formes de logiciel. S'il était concevable que chacun des problèmes pris isolément soit résolu, la probabilité qu'ils puissent tous l'être dans les délais et de façon mutuellement compatible était pratiquement nulle, surtout compte-tenu des nombreux débats internes quant aux différentes voies de solution envisageables.

Les développements de FS furent plus onéreux que prévu. Des concepts qui nous sont aujourd'hui familiers n'existaient alors même pas, et les découvrir a impliqué beaucoup d'essais, de fausses pistes et de tâtonnements.

Les principes de FS

L'accès aux données

Un principe essentiel de FS était celui de la mémoire à un seul niveau ("single-level store") qui étendait l'idée de mémoire virtuelle à la totalité des données, temporaires ou persistantes, et rendait invisible au programmeur une quelconque différence entre accès à une base de données, à un fichier ou à un objet en mémoire. La mémoire de travail, les fichiers et les bases de données étaient accessibles de façon uniforme à travers une généralisation de la notion d'adresse. Les développeurs n'avaient donc pas à se soucier de la localisation physique des objets auxquels ils accédaient, ce qui devait faciliter la programmation et réduire les coûts de développement de logiciel.

Le réalisation de ce principe demandait que le mécanisme d'adressage, qui est au cœur de la machine, incorpore un système complet de gestion de la hiérarchie des mémoires et des parties importantes d'un système de gestion de bases de données, qui jusque là étaient réalisées sous forme de logiciels extérieurs à la machine proprement dite.

Le processeur

Un autre principe était l'utilisation d'instructions de haut niveau très complexes réalisées sous forme de microcode. Par exemple, une des instructions, CreateEncapsulatedModule, était un éditeur de liens complet. D'autres instructions étaient conçues pour supporter les structures de données et les opérations des langages de programmation de haut niveau tels que FORTRAN, COBOL et PL/I. En réalité, FS était conçu comme l'ordinateur à jeu d'instruction complexe (CISC) ultime

Une autre façon de présenter la même idée est de dire que tout l'ensemble des fonctions qui auparavant étaient réalisées sous forme de circuits, de logiciel système, de logiciel de bases de données, et plus encore, étaient maintenant considérées comme faisant partie d'un seul système intégré, chacune des fonctions élémentaires étant implémentée dans l'une des nombreuses couches allant des circuits au logiciel conventionnel. Plusieurs couches de microcode et de code étaient prévues, quelquefois désignées par les termes de millicode et de picocode. Selon la personne qui parlait, la notion même de "machine" pouvait varier depuis les seules fonctions réalisées sous forme de circuits (pour le spécialiste des matériels) jusqu'à la totalité des fonctions offertes aux utilisateurs, indépendamment de leur réalisation (pour les architectes système).

Le plan d'ensemble prévoyait aussi un "contrôleur universel" pour traiter principalement les opérations d'entrée-sortie en dehors du processeur principal. Ce contrôleur universel devait avoir un jeu d'instructions très limité, réduit aux instructions nécessaires aux entrées-sorties. Il annonçait ainsi le concept d'ordinateur à jeu d'instructions réduit (RISC).

Sur cette idée, John Cocke, un des principaux concepteurs des premiers ordinateurs IBM, lança un projet de recherche destiné à concevoir le premier ordinateur RISC. Par la suite, l'architecture RISC, qui au sein d'IBM évolua vers l'architecture Power et PowerPC, devait se révéler beaucoup moins chère à réaliser et capable en théorie de cadences d'horloge bien supérieures. Dans la pratique, Apple abandonnera plus tard ces processeurs, parce qu'ils ne montent pas suffisamment en fréquence, pour utiliser des Intel.