Je n’ai pas connu chez Bull la période de conception du Gamma 60 et si je l’ai aperçu dans les salles d’ordinateur de Gambetta et de la SNCF, si je lui ai soumis quelques calculs par l’intermédiaire de programmeurs, je ne suis pas un témoin de cette « aventure ». Ayant été mêlé à la fin des années 60 à une autre[1] « aventure » de conception de systèmes, j’ai eu la curiosité d’essayer de comprendre ce qui se passait dans la tête des concepteurs de Bull en 1955 et un peu après.
Jean
Bellec 11 août 2003
Le
Gamma 60 a été conçu au milieu des années 1950, à un moment où les
installations mécanographiques des gros clients commençaient à être dotées
de nombreuses machines (tabulatrices, calculatrices, trieuses …) dont
l'exploitation (manipulation de cartes, montage et démontage des tableaux de
connections) commençaient à représenter des causes d’erreurs et un coût
important.
En
parallèle, de nouvelles technologies avaient fait leurs preuves aux États-Unis.
Ce furent essentiellement le stockage des données sur bandes magnétiques et
l'arrivée de technologies plus fiables et plus performantes avec les mémoires
à tores et les circuits transistorisés.
La
genèse du Gamma 60 a été longue puisque le premier système devint opérationnel
en 1961, si bien que d'autres facteurs postérieurs aux premières études (et
à leur annonce quelque peu prématurée) furent plus ou moins habilement pris
en compte.
En
1955, Bull était incontestablement le second constructeur d’équipements mécanographiques
en Europe et peut-être au monde (bien que l’existence d’accords avec
Remington Rand rende difficile l’analyse de la place relative de Bull sur le
marché mondial).
Le
constructeur de matériel mécanographique faisait essentiellement un matériel
dont la technologie relevait tantôt de la machine-outil tantôt de
l’horlogerie lourde. La technologie était d’abord de la mécanique de précision,
agrémentée d’une part de plus en plus importante d’électromécanique
(la technologie à relais et les totalisateurs).
Le
réseau commercial avait un rôle primordial, d’abord parce que la majorité
des systèmes était placée en location et ensuite parce que les clients
avaient besoin d’assistance technique pour tirer partie des machines. Les
techniciens de Bull réalisaient la plus grande partie de la « programmation »
des ensembles mécanographiques en piquant les tableaux de connections.
Au
début des années 1950, Bull avait complété sa gamme d’outils mécanographiques
avec une calculatrice électronique le Gamma 3, qui s’affranchissait des
limitations apportées par la calculatrice électromécanique sur le débit
des ensembles mécanographiques.
La
mécanographie « classique » souffrait cependant de plusieurs
inconvénients :
Beaucoup
de travaux se trouvaient concentrés en fin de mois et d’année ce qui
impliquait généralement un dimensionnement de l’équipement pour les périodes
de pointe. La vitesse de lecture des cartes et d’impression étant limitée
à 150 cartes ou lignes par minute, la seule solution était de faire
coexister plusieurs équipements sur un site, ce qui posait des problèmes
d’exploitation difficiles pour synchroniser les échanges de fichiers entre
équipements.
Certaines
applications chez les clients (spécialement les banques et assurances car les
impôts et les abonnés des
services publics n’étaient pas encore totalement mécanisés) nécessitaient
de gros fichiers dépassant les capacités des trieuses et autres
interclasseuses.
Ces
problèmes recevaient potentiellement une solution en mettant les fichiers
permanents sur bandes magnétiques, solution déjà en service aux États-Unis
depuis le début des années 1950 avec les machines UNIVAC. Bien entendu
l’actionnaire de référence de Bull (les Papeteries Aussedat) ne pouvait
pas ne pas hésiter devant une solution qui pouvait tarir une source
importante de ses profits. Seule une solution combinant matériel à cartes et
bandes magnétiques lui était acceptable, d’autant plus que les
convertisseurs utilisés par Univac posaient bien des problèmes pour les
petits fichiers. La solution mixte (cartes et bandes) fut aussi retenue par
IBM dans ses systèmes 702 et 705 qui commençaient à apparaître à l’époque
de conception du Gamma 60.
La
technologie à tubes à vide de la calculatrice Gamma 3, même miniaturisés,
n’était pas sans poser des problèmes de coût et de fiabilité. La
technologie à transistors commençait en 1955 à apparaître avec des
avantages d’encombrement, de fiabilité et de dissipation calorifique, sinon
de prix à l’époque. Bull, n’étant en rien lié aux fabricants de tubes
(tels CSF ou Philips), pouvait facilement faire le choix du transistor
qu’elle avait effleuré dans son utilisation des diodes à semi-conducteurs
dans le Gamma 3. Ce choix du transistor était quand même un pari car la SEA
française et des constructeurs japonais croyaient à l’époque davantage
aux technologies magnétiques (plus fiables…et plus encombrantes, mais on ne
parlait pas à l’époque d’intégration des circuits…)
Au
milieu des années 1950, les constructeurs américains avaient commencé à
abandonner diverses solutions de technologies à mémoires pour se concentrer
sur les tores magnétiques. Les tores, bien que posant des problèmes de coût
de main d’œuvre pour leur tissage, permettaient une grande fiabilité et un
temps d’accès bien plus réduit que les technologies alternatives (lignes
à retard, tube de Williams…). Les mémoires à tores s’accommodaient bien
d’une logique parallèle (telle qu’initialement suggérée par Von
Neumann). Elles permettaient en particulier de s’affranchir de la « programmation »
(type Harvard) des tableaux de connexions et de nourrir toutes les spéculations
nées dans les années 1950 sur les machines auto-modifiables et
intelligentes.
Jusque
là, l’approche de Bull n’était guère différente de celle de
IBM-Poughkeepsie ou de RCA. Cependant, Bull n’était pas un leader dans ces
technologies (bandes magnétiques et mémoires à tores avaient été conçues
aux USA) et pensait devoir consolider sa position par des innovations
conceptuelles. Parmi celles-ci, née de l’expérience de la mécanographie,
l’idée s’imposa d’une planification centralisée de l’exploitation de
l’atelier mécanographique alors composé d’un ensemble de plusieurs
machines opérant en parallèle et difficiles à synchroniser. Une mémoire
commune stockant à la fois les programmes locaux et la synchronisation de
l’exploitation de ceux-ci semblait résoudre le problème de la
planification des travaux, des tableaux de connexions amovibles et des paquets
de cartes à répartir entre machines.
Les
machines à synchroniser étaient les unisélecteurs de bandes magnétiques
(ou de tambours), les lecteurs et perforateurs de cartes, les imprimantes et
les calculatrices. L’analyse des besoins les plus complexes des tableaux de
connexions de tabulatrices-imprimantes conduisit à la conception d’un véritable
processeur spécialisé : le Traducteur.
On
voit se dessiner l’architecture du Gamma 60 qui ne doit à peu près rien
aux machines IBM comme le 704, conçu autour de la résolution de problèmes
scientifiques aux calculs longs et séquentiels, ni même au Gamma ET dont la
diffusion et l’utilisation en scientifique est à peu près contemporaine de
la conception du Gamma 60. Bien entendu, qui peut le plus peut le moins, le
Gamma 60 fut doté d’une unité arithmétique décimale comme le Gamma ET et
se porta candidat aux mêmes applications.
Design
logique.
Les
objectifs initiaux conduisaient à interconnecter les différentes machines mécanographiques
(y compris les nouveaux dérouleurs de bande magnétique) entre elles et à en
assurer une administration centralisée. Les performances des nouvelles
technologies (et en particulier de la mémoire à tores) semblaient autoriser
une économie de coût grâce au partage de matériel entre les différents éléments.
Outre les appareils (bandes, cartes, imprimantes) dont le fonctionnement était
naturellement asynchrone, l'idée de conserver un fonctionnement asynchrone
pour le calculateur arithmétique et ce qui deviendra le traducteur était
naturelle.
L'étude
de l'architecture du système conduisit à faire du contrôleur de mémoire (distributeur
de quantités) et de son protocole d'accès le centre du système. Toutes
les fonctions du système furent construites sur cette base.
Les temps de traitement des opérations d'informatique de gestion étaient, malgré la transistorisation, relativement lents par rapport au cycle de mémoire centrale en particulier les fonctions portant sur des structures longues d'information et sur les opérandes numériques de grande précision. C'est ainsi que le traducteur, le calculateur arithmétique, le comparateur furent construits comme des "éléments" indépendants et asynchrones au même titre que les contrôleurs de périphériques.
L'organisation
des traitements d'informatique de gestion se faisait déjà en UT unités
de traitement (que l'on appellera plus tard job steps) dont le
déroulement soit était nécessairement séquentiel soit était susceptible
d'être exécuté de manière asynchrone. L'idée qui vint aux concepteurs du
Gamma 60 était d'exploiter les possibilités de fonctionnement autonome des
"éléments" pour pouvoir exécuter les UT potentiellement
asynchrones en "simultanéité".
La
gestion de toutes les phases asynchrones des machines au profit d'UT
asynchrones était confiée à un "élément" spécialisé : le
distributeur de programmes implanté dans l'unité centrale mais opérant de
manière identique aux autres éléments.
Le
distributeur de programmes interprète les instructions centrales ou
canoniques qu'il lit en mémoire centrale et qui sont essentiellement des
instructions de "mise au travail" d'un autre élément et de
branchement (inconditionnels ou conditionnels sur les catènes qualitatifs -
statut des opérations des autres éléments). Outre la mémoire centrale, le
distributeur peut accéder aux registres des autres éléments.
La
mise au travail (ou à l'arrêt) des "éléments" se fait à l'aide
d'une instruction de "coupure" qui préfixe un bloc de commandes
comprenant des commandes (directives) spécifiques de l' "élément".
Au préalable, des adresses en mémoire centrale avaient été chargées dans
des registres RAQ du distributeur de quantité (spécifiques de l' "élément").
Cette instruction de coupure a en fait pour effet de mettre en queue la requête
dans une chaîne de reprise dont un maillon se trouve dans chaque bloc de
commandes. Le distributeur de programmes passe ensuite sur d'autres fonctions
asynchrones faisant l'objet d'autres DTI. Ce sont le plus souvent des
notifications de fin d'opération asynchrone.
De
façon à permettre les traitements asynchrones à l'initiative du programmeur
- et non pas simplement à l'initiative de l'opérateur du pupitre - une
instruction de "simu" représente l'équivalent de la coupure mais
le programme se poursuit dans le distributeur de programmes qui peut mettre au
travail d'autres "éléments".
L'adresse
de retour en fin de directive est rangée dans un registre RAP de l'élément.
Le
distributeur de programmes est lui-même un "élément" et accède
à la mémoire centrale banalisée via le distributeur de quantités.
Plus
tard, certains programmes utiliseront la "coupure sur élément
virtuel" à des fins de synchronisation des processus logiciels, voire à
des traitements de listes.
Les
éléments centraux sont tous de types différents. Aucun Gamma 60 ne fut
construit avec par exemple deux calculateurs arithmétiques bien que rien ne
l'interdise dans l'architecture. C'est un abus de langage que d'attribuer au
Gamma 60 le rôle de premier multiprocesseur de l'histoire. Les types d'éléments
centraux sont le calculateur arithmétique, le comparateur général, le
comparateur logique et le traducteur. Faute d'analyse préalable des besoins
(la métrologie du logiciel qui a amené à la conception des architectures
postérieures à 1975) la spécialisation des fonctions et les caractéristiques
des éléments centraux n'ont pas été définies de manière tout à fait
rationnelle.
Le
Gamma 60 n'était pas destiné aux applications scientifiques (militaires ou
civiles) et une impasse a été faite sur le calcul binaire à grande précision,
à l'époque le calcul matriciel. Un calculateur arithmétique binaire avait
été promis à un grand utilisateur mais n'a pas été construit. Le calcul
de fonctions trigonométriques ne semble pas non plus avoir été envisagé.
Le
calculateur arithmétique opérant sur des opérandes en décimal
flottant est l'héritier du Gamma 3. Le décimal flottant avait surtout pour
lui d'être directement compatible avec les appareils d'entrées-sorties (les
nombres sur carte perforée n'affaiblissaient pas la résistance physique de
la carte et l'on économisait le temps de conversion binaire décimal qui
aurait encore alourdi la fonction du traducteur). Le calculateur arithmétique
possédait un opérateur parallèle sur 80 bits et traitait des opérandes sur
48 bits.
L'indépendance
du calculateur logique semble avoir été due à l'importance donnée
à cette époque à l'algèbre de Boole et à ce dont beaucoup rêvaient,
celle de l'intelligence artificielle. Il faut noter cependant que
l'organisation des données en structure de listes (telle que le sous-entend
McCarthy dans LISP) est seulement contemporaine du Gamma 60 et n'était pas
connue des designers, même si ceux-ci en élaborèrent un mécanisme spécialisé
dans la gestion des tâches (cf. chaînes de reprise).
Le
comparateur général a, outre les instructions de comparaison, la
fonction d'effectuer des MOVE de mémoire à mémoire, ce qui
justifiait probablement son fonctionnement asynchrone. Il était fondé sur un
opérateur série.
Le
traducteur était essentiellement l'héritier de la logique distribuée
des équipements mécanographiques en allégeant la fonction des éléments
cartes imprimantes, en admettant le support des cartes IBM (pardon, des cartes
Hollerith). Le traducteur était en fait un processeur distribué avec
ses propres programmes (clichés) et des traitements complexes de
caractères pour la mise en page des états d'imprimantes.
Les
contrôleurs de périphériques semblent plutôt allégés quand on les
compare aux systèmes plus récents (post-1964) et furent essentiellement
consacrés à l'optimisation des débits de données et aux fonctions temps réel
imposées par la mécanique. La solution retenue par le Gamma 60 de ne pas
rendre les conversions unit-record à bandes magnétiques des phases
obligatoires (comme le faisaient l'Univac I qui recourait à des
convertisseurs off-line, et l'IBM 702 qui ne disposait pas des canaux simultanés
seulement inventés sur le 705) était considérée à juste titre comme un
atout.
Un
des problèmes les plus épineux du design du Gamma 60 fut la réduction des
risques de fiabilité introduits par les technologies nouvelles :
transistor, mémoire à tores, bande magnétique. Le développement par
Bull de toute la partie électronique des ensembles utilisant ces technologies
représenta un challenge impressionnant quand on considère que, à part un
peu chez SEA, la Compagnie des Machines Bull ne pouvait guère recruter des
ingénieurs ayant développé ces technologies et devait redécouvrir caractéristiques
physiques et solutions aux problèmes rencontrés. Là où IBM bénéficiait
du projet SAGE et du support de contrats de la NSA, Bull ne disposait pas et
ne recherchait guère de contrats publics sur ces technologies.
En
dehors des mécanismes strictement liés à la technologie, de nombreuses
stratégies de redondance durent être incorporées à la logique et contribuèrent
à l'instabilité du design. Elles contribuèrent à une augmentation considérable
du volume de la machine et, indirectement, en augmentèrent la probabilité de
pannes.
Les 24 plans de la mémoire à tores furent complétés par 3 plans de correction d'erreurs, portant la largeur du contrôleur de mémoire à 27 bits. Le calculateur arithmétique fut doté de circuits de calcul de preuve. La totalité de la machine et non pas seulement les "éléments" fut synchronisée par un distributeur de rythmes qui devait porter sur des longueurs très grandes et des circuits de régénération des signaux horloge dans chaque cabinet. L'hypothèse d'un "worst case design" où tous les transistors étaient supposés dévier dans le même sens des performances nominales fut prise, ce qui compliqua encore la distribution des signaux d'horloge. La technologie de base fut ralentie à peu près de moitié pour tenir compte de ce design, conduisant à une baisse de performances équivalente. Il est vrai que des règles de design moins contraignantes auraient entraîné davantage de corrections sur les « chaînes longues » et vraisemblablement des mises au point en clientèle encore plus nombreuses. Il faut noter la présence sur le Gamma 60 d’un nombre important de points de mesure et de potentiomètres de marge qui certainement en augmentèrent les coûts et impliquaient la présence quasi permanente d’ingénieurs de maintenance sur le site.
Les ingénieurs des Études Bull ignoraient en 1955 ce qu’on appela plus tard la « computer science » ou plutôt en étaient restés au rapport Von Neumann sur EDVAC. Ce n’est qu’en 1961 que le software fut enseigné à Bull par le professeur Perlis, mais c’était déjà près de la fin de l’aventure. La plupart de ces ingénieurs ne parlaient pas anglais et étaient plutôt fiers de l’ignorer. Et surtout, la reproduction des documents par photocopie ne se répandit qu’à la fin des années 1960 et la possession d’un document technique américain ne servait qu’à augmenter le pouvoir de son détenteur, privant ses collègues d’une comparaison avec le projet en cours. Les services technico-commerciaux furent, eux, plus sensibles aux demandes des clients et c’est en leur sein que furent développés ou conçus la plupart des développements de logiciel de base, en particulier au CNCE (centre national de calcul électronique). C’est ainsi que furent développés un moniteur séquentiel, un compilateur Algol, que fut pensé l’AP3… Malheureusement, ces développements ne commencèrent que très tardivement et furent plutôt mal coordonnés avec les architectes des Études.
Le
logiciel, on disait encore software, sous la forme qu'il revêtait
à la fin des années 1950, c'est à dire un superviseur d'entrées-sorties et
un moniteur d'enchaînement des travaux, ne fut entrepris qu'après la réalisation
du matériel et les commandes des clients. Seuls étaient dérivés du Gamma 3
le concept de sous-programmes standard (ouverts ou fermés) pour le tri ou des
fonctions scientifiques. Le problème classique du passage des paramètres ou
du rangement de l'adresse retour dans les procédures ne fut aussi abordé
qu'après la réalisation des prototypes. La solution des éléments virtuels
pour appeler une procédure était à tout le moins lourde. Pourtant ce problème
était connu et résolu en Grande Bretagne avec Maurice Wilkes. Les
"sous-programmes ouverts" représentaient l'insertion "en
ligne" de code et étaient souvent présentés comme des solutions préférables
aux "procédures", probablement en héritage des programmes par
cartes. On comprend bien que le Gamma 60 est arrivé trop tôt pour un
compilateur COBOL, mais le retard découvert avec l’importation du RCA 301
et encore plus tard avec le GE-400 contraste avec la confiance que Bull à la
fin des années 1950 avait dans la pérennité du Gamma 60.
Le Gamma 60 inaugure en un certain sens l'architecture des processeurs superscalaires[2] des années 1990 où le rôle de la mémoire centrale est remplacé par celui du (ou des) cache. Il se rapproche aussi des architectures EPIC[3] par le fait que la simultanéité d’exécution et la cohérence des accès mémoires est placée sous la responsabilité du programmeur. Cependant cette prémonition était certainement inconsciente car l'existence même d'un système logiciel (système d'exploitation, langages standard indépendants de l'architecture machine) ne semblait pas être soupçonnée au moment de la conception.
Par
contre, la conception de la simultanéité des entrées sorties par une
gestion asynchrone devance un peu l'adoption généralisée par IBM de la
solution inaugurée sur la 709. On peut cependant regretter que le concept
d'un IOC gérant séparément du processeur central et regroupant les
registres des éléments périphériques[4]
n'ait pas été inventé sur le Gamma 60.
Par
ailleurs, s'il était assez raisonnable de lancer un programme multi-threads
sans aucune protection entre ces tâches (après tout, les systèmes actuels
sous UNIX et Windows XP en font autant), il était pour le moins imprudent
d'annoncer que ces programmes pouvaient être indépendants. Le Gamma 60
n'avait pas de système de protection de mémoire et les chaînes de reprises,
outils essentiels du dispatching des programmes, étaient exposées à tout
programme malveillant ou simplement erroné. De même, l'absence d'un mode maître
(superviseur) autorisait l'accès aux "éléments périphériques"
sans aucun contrôle.
Le
Gamma 60 était limité en taille mémoire à une capacité de 32K mots de 24
bits -il faut le dire d’une taille comparable à celle de la concurrence-.
Il n'envisagea pas de recourir au concept de mémoire virtuelle introduit dans
le Ferranti Atlas pourtant contemporain. Ses tambours n'étaient destinés
qu'au stockage de programmes ou au stockage de petits fichiers séquentiels.
La longueur des mots, inférieure à ses compétiteurs scientifiques IBM et
Univac[5],
aurait probablement dû être étendue pour faire bénéficier le système de
ce concept.
Les
concepteurs du Gamma 60 inventèrent cependant bien des concepts de l’an
2000 sans être conscients de leur portée.
En pratique, il n’était pas possible de tirer parti de toutes ces inventions d’architecture avant les années 1980. La mémoire centrale du Gamma 60, 32K catènes, était de la taille d’un cache L2 d’aujourd’hui (et 10 000 fois plus lente). La mémoire paraissait rapide devant la lenteur des calculs. Les trois décennies suivantes renversèrent la vitesse relative de la mémoire et du processeur avant de retrouver un rapport voisin sur la base du cache.
La
capacité théorique du Gamma 60 à recevoir plusieurs processeurs de même
type ne fut jamais exploitée, pas plus que ne fut développé un calculateur
flottant binaire nécessité par les traitements SIMD
(traitements matriciels sur tableaux de données) graphiques ou autres.
Le
concept de multiprogrammation qui consistait dans les années 1960 à
effectuer simultanément des programmes disjoints rentra au chausse-pied dans
le Gamma 60 qui n’avait pas été conçu pour le fonctionnement de
programmes indépendants en cours de debugging. Le manque de dispositif
de protection de mémoire était pour cela un obstacle plus qu’important.
Seuls en pratique les programmes « coopérants » pouvaient y accéder
en simultanéité. Les premiers programmes multi-threads apparurent
dans les programmes transactionnels de 1975.
La
compilation d’un code source pour une architecture EPIC permettant un
fonctionnement automatique de la simultanéité n’a vu le jour qu’à la
fin des années 1990 après un développement qui excède la durée de vie du
Gamma 60. Inutile de reprocher aux concepteurs de 1955 qui ignoraient souvent
même jusqu’au concept de compilateur, de ne pas l’avoir développé.
Qu’il
soit permis de s’étonner que ce système ait finalement fini par être
construit et même mis en service à la satisfaction d’une grande poignée
de clients alors qu’il aurait pu accompagner certaines machines expérimentales
de Univac (LARC), Burroughs (Illiac), IBM (SSEC, NORC), SEA (Dorothée, 1500)
dans le respect des archéologues de l’histoire de l’informatique.
Probablement,
le Gamma 60 aurait pu mieux féconder les équipes de développement de Bull,
comme l’a fait le Stretch IBM, si la débâcle financière de la Compagnie
n’en avait entraîné le démembrement. Par contre, c’est davantage le
choix stratégique de ne pas avoir vu que l’informatique avait cessé de
n’être qu’une automatisation de la gestion taylorienne des entreprises et
la fuite en avant dans une gestion aventureuse du parc (obsolescence programmée
du matériel « classique ») qui ont été à l’origine de la
chute de 1963 plus que les coûts de R&D du Gamma 60.