Le projet Future Systems (FS) est un projet de recherche et développement entrepris par IBM au début des années 1970. Il visait à introduire une ligne informatique nouvelle orientée spécifiquement sur la simplification du développement d'applications - afin essentiellement d'en accélérer la croissance, et donc celle de ses ventes. Ce projet a été abandonné en 1975, bien que certaines de ses idées aient été utilisées ensuite pour le système 38, puis l'AS/400, en particulier la principale : l'espace d'adressage unique (à ne pas confondre avec la mémoire virtuelle).
Objectifs généraux
Jusqu'à la fin des années 1960, IBM tirait son revenu et ses profits du matériel. Logiciel et services de support, considérés comme aide à la vente, n'étaient en effet pas facturés. Seuls les matériels figuraient au tarif, mais leurs prix couvraient aussi les coûts des logiciels et des services.
D'autres fournisseurs avaient commencé à offrir des matériels compatibles, principalement des périphériques comme des unités de bande et de disques magnétiques, à des prix significativement inférieurs à ceux d'IBM, réduisant ainsi la base sur laquelle il était possible de récupérer le coût des logiciels et des services. Au début de 1971, après que Gene Amdahl eut quitté IBM pour créer sa propre entreprise (Amdahl Corporation) proposant des unités centrales compatibles IBM, une "taskforce" interne IBM (projet Counterpoint) concluait que la prise en charge sans contrepartie de tous les frais de logiciel par IBM ne pouvait que favoriser la compétitivité des unités centrales et autres produits d'une concurrence n'ayant aucun de ces coûts à supporter. Il fallait donc facturer les logiciels.
Cela était d'autant plus vrai que les coûts des matériels informatiques étaient en diminution constante tandis que ceux de programmation et d'exploitation, constitués essentiellement de coûts de personnel, iraient, eux, en augmentation (bien que partiellement pondérés par une large extension de la base installée). L'amélioration du seul rapport performance/coût des machines ne conduisait donc pas nécessairement au développement des ventes. Une nouvelle architecture réduisant coûts de développement et d'exploitation améliorerait en revanche largement la croissance d'IBM, puisqu'aidant les utilisateurs à développer davantage d'applications chaque année.
L'idée d'un espace d'adressage unique combinant mémoire centrale et espace disque mettant fin pour le programmeur au souci de jongler entre la mémoire centrale et le disque (phases et overlays) était séduisante. Celle de laisser au système le soin de gérer cela de façon plus logique que la mémoire virtuelle en tirant parti des caractéristiques d'accès s'imposa.
IBM était par ailleurs attaquée juridiquement : pour sa position dominante pour sa politique d'inclusion gratuite du logiciel et des services avec le matériel, ce qui pouvait être jugé comme de la concurrence déloyale envers les sociétés de service et quelques entreprises de logiciel; cela donnait donc un motif d'abandonner cette gratuitéQui avait ses raisons : le logiciel était alors un moyen de faire augmenter les besoins en matériel, tout comme en 2010.
Toute politique de vente liée devait donc s'appuyer sur des arguments techniques solides et défendables juridiquement.
En mai-, une "task force" internationale fut réunie à Armonk par John Opel, alors vice-président d'IBM. Sa tâche était d'explorer la faisabilité d'une nouvelle ligne d'ordinateurs. Ceux-ci rendraient obsolètes les compatibles, mais pour le coup aussi la ligne existante d'IBM. Cette "task force" conclut que le projet pouvait être accepté par le marché, mais - sans surprise - uniquement si la réduction annoncée des coûts de développement, exploitation et maintenance des logiciels d'application était suffisamment massive pour justifier cette révolution.
La direction d'IBM décida d'entreprendre le projet en confirmant les objectifs suivants :
rendre obsolètes tous les ordinateurs existants, y compris ceux d'IBM, en exploitant pleinement les techniques logicielles et matérielles du moment , réduire fortement les coûts de développement et d'exploitation des applications, regrouper autant qu'il était possible les offres d'IBM (matériels, logiciels et services).
Autres problèmes prévus en fin des années 1960 pour la fin du siècle Le projet FS prenait également en compte les problèmes suivants pressentis par IBM : les imprimantes à impact ne pourraient rapidement plus suivre les débits d'information; les délais pour en changer les chaînes d'impression (48 caractères pour la vitesse, 64 ou 96 caractères pour la richesse du jeu); les changements de bandes-pilote ou de préimprimés introduisaient encore des délais supplémentaires. la technique des écrans se séparait trop brutalement en écrans texte abordables et d'usage facile d'une part et écrans graphiques très coûteux et complexes à mettre en œuvre d'autre part; les besoins intermédiaires (graphiques de gestion) n'avaient pas de réponse et c'était là qu'allait se porter la demande; les télécommunications relevaient de bricolages spécifiques et non compatibles entre eux. un terminal (écran ou machine à boule) était attaché à une application donnée et complexe à rattacher à une autre; même quand ce rattachement était possible, il demandait à chaque fois des compétences spécifiques différentes; les questions de polices de caractères (en particulier APL) n'étaient pas gérées de façon automatique, ni même cohérente sur l'ensemble de la chaîne de traitement : c'était là encore à l'utilisateur de s'en occuper, et de signaler son action au système - la détection n'étant pas automatique. les délais de montage et démontage des bandes magnétiques bloqueraient de plus en plus les systèmes l'organisation hiérarchique des fichiers conduirait à des inefficacités croissantes en termes de maintenance à mesure qu'on dépasserait la dizaine de milliers de fichiersÀ l'heure actuelle, une station de travail Linux comporte souvent de quelques centaines de milliers à plus d'un million de fichiers). les systèmes existants n'incorporaient pas la notion de migration automatique d'un document entre supports sans perte d'identité comme le fait pourtant n'importe quelle administration (bureau, armoire, transmission entre services, salle d'archives...).
Historique du projet Lancement du projet
Le projet Future Systems (FS) fut lancé officiellement en septembre 1971, à la suite des recommandations de la "task force" du deuxième trimestre 1971Pour mémoire, le 370/155 avait été annoncé en janvier 1971 et le 370/148 le sera en 1977. Par la suite, plusieurs autres projets de recherche dans divers sites d'IBM fusionnèrent avec le projet ou lui furent associés.
Gestion du projet
Pendant toute sa durée, le projet FS se déroula dans des conditions de sécurité et de confidentialité très strictes. Le projet était divisé en nombreux sous-projets affectés à des équipes différentes. La documentation était découpée de la même façon en nombreux éléments, et l'accès à chaque document était soumis à vérification de la réalité du besoin réel par un organisme central du projet. Chaque document faisait l'objet d'un suivi et pouvait être rappelé à tout moment.
Une conséquence était que la plupart des personnes qui travaillaient sur le projet n'en avaient qu'une vue extrêmement fragmentaire, limitée à ce qu'ils devaient en savoir pour produire la contribution qu'on attendait d'eux. Certaines équipes travaillaient même pour le projet sans le savoir. Cela explique pourquoi, quand ils sont amenés à définir ce qu'était FS ou pourquoi le projet a été abandonné, la plupart des gens donnent une réponse très partielle, qui ne mentionne que la partie du projet FS qui entre dans leur domaine de compétence.
La mobilisation fut grande : "le projet FS a mobilisé . Ses responsables avaient des droits de tirage sur le personnel de toutes les unités IBM. J'avais un travail à Paris et on m'en a sorti du jour au lendemain pour m'envoyer à New York. Pour vous montrer la foi qu'on avait dans IBM, je n'ai pas entendu dire que quelqu'un ait refusé cette mobilisation, ni l'ait regrettée"Jean-Jacques Duby, directeur du développement scientifique à IBM France; article mentionné en lien externe
Les lignes de produits prévues
Trois implémentations de l'architecture FS étaient prévues : le modèle de haut de gamme était conçu à Poughkeepsie (État de New York), où étaient produits les ordinateurs les plus puissants d'IBM ; le modèle de milieu de gamme était conçu à Endicott (État de New York), qui était responsable des ordinateurs de milieu de gamme ; le plus petit modèle était conçu à Rochester (Minnesota), qui avait la responsabilité des ordinateurs d'entrée de gamme.
Une gamme continue de performances pouvait être obtenue en faisant varier le nombre de processeurs par système à chacun des trois niveaux d'implémentation.
Au début de 1973, la direction d'ensemble du projet, ainsi que les équipes responsables des couches les plus externes communes à toutes les implémentations furent regroupées au laboratoire ASDD de Mohansic, à mi-chemin entre les sièges d'Armonk/White Plains et Poughkeepsie.
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 prenait la relève de l'idée de mémoire virtuelle en l'étendant à la totalité des données, temporaires ou persistantes. Cela 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 (on prévoyait au départ une adresse généralisée de ). Les développeurs n'avaient donc pas à se soucier de la localisation physique des objets auxquels ils accédaient, mais uniquement de leur type et de leur nom, ce qui devait faciliter la programmation et réduire les coûts de développement de logiciel.
La 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. . 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) ultimeBurroughs dans le même temps travaillait sur un projet similaire : ce sera le Burroughs B1700, faisant appel à des microcodes différents en fonction du langage source utilisé. Cette approche ne se révélait cependant efficace que si tous n'étaient pas utilisés en même temps dans le contexte de la multiprogrammation
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).