--ooOoo--

          Le calculateur IBM 1620, orienté cartes et rubans perforées, était la machine installée au Bureau d'Etudes de l'usine de SUD AVIATION quand j'ai été embauché comme programmeur débutant. Je ne dissimule d'ailleurs pas mon plaisir à décrire cette machine qui fut mon vrai premier contact avec l'informatique d'entreprise.

           Dans trois armoires, cette machine se composait des 5 éléments suivants  :

1. l'unité de mémoire tout derrière IBM 1623,
2. l'unité centrale IBM 1620 avec son pupitre plein de lumières !..,
3. le clavier de clés et de boutons-poussoirs,
4. la console KSR 33 à ruban perforé
5. le lecteur/perforateur de cartes IBM 1622.

          L'ensemble était complété de deux types de machines auxiliaires :

1. de 3 perforatrices de cartes IBM 029,
2. d'une trieuse IBM 82.

La perforatrice IBM 029

La trieuse IBM 82

          Une unité qui me tînt à coeur et que j'ai fini par enfin obtenir fut le traceur de courbes IBM 1627 ci-dessous dont je parlerais dans le traitement de la fabrication des moules de pales en fibres synthétiques :

I - Le calculateur proprement dit :

L'unité de mémoire :

          L'unité de mémoire, avec plein de lampes comme on pouvait en voir dans les anciens poste de radio, était une armoire quasiment remplie par les blocs de mémoire à tores de ferrite, si je me souviens bien, qui dégageait une intense chaleur refroidie par deux énormes ventilateurs situés de chaque côté.

         La taille de cette mémoire était de 20000 positions décimales en code BCD (Binary Coded Décimal) qui devait contenir programme et données.

L'unité centrale :

          L'unité centrale était un bloc posé sur une table montrant en façade, quand le calculateur travaillait, tout un ensemble de lumières clignotantes qui affichait les différents registres de la machine et en particulier son registre d'état avec son compteur ordinal.

          Pour donner un aperçu, j'ai retrouvé les caractéristiques de performances de la machine au cycle de base de 21 µsecondes :

Le clavier de clés et de boutons-poussoirs :

          Grâce aux clés (photographie ci-dessus), nous pouvions pré-initialiser ses registres avant d'appuyer sur le bouton "Start" pour démarrer le programme à exécuter.
          C'est aussi grâce à ces boutons et ces clés que nous pouvions "debugguer" le programme avec l'aide de la console un KSR 33 que nous voyons ci-après.

La console KSR 33 à ruban perforé :

          Cette télétype permettait de concevoir des programmes conversationnels. Elle imprimait jusqu'à 10 caractères par seconde et elle avait un clavier pour saisir du texte alphanumérique. C'est tout simplement le mode console que l'on voit aujourd'hui sur les calculateurs et qui est une reconduction de la fonctionnalité.

          Par ailleurs, j'ai eu l'occasion aussi de m'en servir pour générer des bandes de programmes de commandes numériques.

Le lecteur/perforateur de cartes :

          Cette unité d'entrées/sorties identifiée IBM 1622 utilisait des cartes au format 80 colonnes ci-contre. La vitesse nominale de lecture était de l'ordre de 600 cartes à la minute et la vitesse nominale de perforation était de l'ordre de 300 cartes à la minute. Ce sont des chiffres de mémoire.
          Cette unité et la télétype KSR33 étaient les seuls moyen de communication avec le calculateur, en dehors des clés du pupitre. Le lecteur/perforateur de cartes étant de loin le plus pratique, elles servaient toutes deux de mémoire de masse :

• à charger des programmes, utilitaires et programmes-utilisateur,

• à générer des paquets de cartes pour communiquer entre plusieurs modules,

• à archiver les programme-source et les programmes exécutables.

• à échanger des informations avec d'autres utilisateurs parfois en dehors de l'entreprise.

II - Les unités auxiliaires  :

          Ces unités nous permettaient de préparer les programmes en vue de les exécuter sur le calculateur. Le langage de programmation était le Fortran II, un langage scientifique. Ces unités étaient de deux types :

La perforatrice de cartes :

          Cette unité IBM 029, aux nombre de 3, nous servait  :

• à perforer les programmes en langage source Fortran à raison d'une instruction dans les 72 premières colonnes de la carte, les colonnes 73 à 80 restant blanches pendant toute la période de mise au point accueillant en général un numéro de séquence de chaque carte..

• à perforer les données que devait lire le programme au moment de l'exécution,

• à reproduire des cartes une à une, cela permettait de modifier des instructions sans avoir à tout ressaisir.

          A l 'une de ces unités était connectée une KSR 33. Elle nous permettait d'imprimer sur papier, en offline, les données que nous perforions sur cartes, sources des programmes, résultats de calculs pour laisser libre le calculateur alors à la disposition d'autres utilisateurs.

La trieuse de cartes :

          Cette unité IBM 82 nous servait  :

• à reconstruire un paquet de cartes que nous aurions lâché par mégarde à condition qu'il y eut une possibilité de tri dans des colonnes de la cartes d'où l'utilité du numéro de séquence des colonnes 73 à 80 des programmes sources. Cela arrivait quelques fois.

• à réordonner, surtout, des cartes perforées dans un premier programme pour les relire dans un autre. Cela peut paraître surprenant, mais il faut bien voir que, avec seulement 20000 positions de mémoire (caractères codés Binary Coded Decimal), cette procédure permettait de concevoir des programme un peu plus gros.

III - Le traceur de courbes :

          Grâce à l'appui des ingénieurs du département recherche qui étaient responsables de la conception puis de la mise en fabrication des moules de pales, nous pûmes convaincre ma hiérachie de la nécessité d'acquérir un traceur de courbes pour le développement de l'application et de la communication avec les différentes équipes concernées par ce projet, très riche à plusieurs titres, relationnels, techniques et organisationnels.

III - L'utilisation du calculateur :

          La faible taille de la mémoire et la vitesse relativement lente du calculateur nous amenait à réaliser des procédures assez laborieuses. Pour donner une petite idée,

• il nous fallait en gros une bonne vingtaine de minutes pour obtenir un exécutable (compilation et édition des liens),

• nous disposions chacun d'une demi heure à trois quart d'heure pour tester chacun notre programme,

• nous étions 7 à faire de la programmation Fortran.

          En faisant un petit compte, à raison d'une heure par personne en moyenne, il était difficile de prétendre à plus d'un passage par jour compte tenu qu'il y avait en plus des calculs de production à effectuer en priorité. Aussi, pour ne pas gâcher son tour, nous voyions et revoyions nos programmes-source que nous pouvions imprimer sur un lecteur 029 connecté à une télétype KSR 33.

Procédure pour exécuter un programme :

          Vu la taille de la mémoire, un programme était un paquet ne dépassant pas 300 à 350 cartes de 80 colonnes qu'il nous fallait monter en mémoire. Voici donc la procédure pour lancer l'exécution d'un programme, procédure qui, aujourd'hui, est automatique. Il fallait :

1. remettre le hardware dans un état initial stable. Pour ce faire, de tête, nous devions :

   • mettre dans une position de départ toutes les clés du pupitre,

   • appuyer sur la touche "RESET" pour remettre tous les compteurs et registres à zéro,

   • appuyer sur la touche "ZERO MEMORY" (si je me souviens bien) pour remettre à zéro la mémoire. Cette opération n'était pas obligatoire mais très vivement conseillée. Par contre, elle ne devait pas être faite si plusieurs modules se suivaient les uns les autres en partageant des données dans le cadre du découpage des applications,

   • placer le sélecteur du pupitre sur le registre d'entrée/sortie à activer (lecteur de cartes/lecteur de rubans perforés),

   • entrer aux clés l'adresse du lecteur de cartes ou du lecteur de ruban. L'adresse 0, celle correspondant aux clés en position de départ, était celle du lecteur de cartes,

   • appuyer sur la touche "ENTER" pour valider cette adresse,

2. placer ensuite le paquet de cartes exécutable précédé de deux cartes qui constituaient le "LOADER" et suivi la plupart du temps des données lues,

3. appuyer sur la touche "LOAD" pour lancer le chargement

4. appuyer sur la touche "START" pour lancer l'exécution du programme.

          La procédure avec le lecteur de ruban était plus rare car beaucoup moins pratique. J'ai peut-être été le seul à m'en servir pour produire des programmes destinés aux machines à commandes numériques.

          Aujourd'hui, la technique est toujours la même. Seulement avec l'évolution des moyens, mémoires, disques, etc... la procédure explicitée ici est complètement automatisée et masquée par le système.

Procédure pour compiler un programme :

          A cause de la faible la taille de la mémoire, le compilateur Fortran 2, le seul que nous avions, était découpé en 2 phases soient deux modules qu'il fallait enchaîner. Ces deux modules correspondaient et correspondent toujours aujourd'hui aux deux phases du compilateur, une troisième maintenant étant celle de l'optimisation :

• la première phase ou première passe consistait à traduire le langage source en code-machine intermédiaire, à signaler les erreurs de syntaxe ou les instructions inconnues, et autres erreurs...

• la deuxième phase ou deuxième passe consistait à recencer toutes les références externes et internes dans deux tables qui permettaient à l'éditeur de liens de construire l'exécutable.

            Pour une plus ample description des modules exécutables et de la mission de l'éditeur de liens, cliquez ici.

          Donc, pour compiler un programme-source, on va retrouver la procédure d'exécution pour les deux phases. Il fallait :

1. remettre le hardware dans un état initial stable :

   • mettre dans une position de départ toutes les clés du pupitre (en général elles restaient positionnées),

   • appuyer sur la touche "RESET" ,

   • appuyer sur la touche "ZERO MEMORY" ,

2. placer ensuite le paquet de cartes de la phase 1 précédé des deux cartes "LOADER" et suivi du langage-source du programme à compiler,

3. appuyer sur la touche "LOAD" pour lancer le chargement de la phase 1

4. appuyer sur la touche "START" pour lancer l'exécution de la phase 1. La machine commençait alors à travailler et nous voyions très bien titiller toutes les lumières. Suivant le nombre de cartes du programme-source, après un temps de calcul entre 5 et 10 minutes, la machine se mettait à perforer un paquet de cartes, résultat de la phase 1. Un message sur la console KSR 33 nous indiquait qu'il fallait charger la phase 2,
   
        Il fallait alors :

5. placer le paquet de cartes de la phase 2 précédé des deux cartes "LOADER" et suivi du paquet de cartes résultat de la phase 1,

6. appuyer sur la touche "LOAD" pour lancer le chargement de la phase 2,

7. appuyer sur la touche "START" pour lancer l'exécution de la phase 2. La machine se mettait alors à travailler. Suivant le nombre de cartes du paquet résultat de la phase 2, après un temps de calcul aussi entre 5 et 10 minutes, la machine se mettait à perforer un paquet de cartes, résultat de la phase 2. Un message sur la console KSR 33 nous indiquait que la compilation du programme était terminée.

          C'est ce dernier paquet de cartes qui constituait le module intermédiaire du programme.

Procédure pour construire l'exécutable d'un programme :

          Pour construire un exécutable, il fallait un programme particulier fourni avec la distribution du système "l'éditeur de liens". Pour ce faire, il fallait :

1. remettre le hardware dans un état initial stable :

   • mettre dans une position de départ toutes les clés du pupitre (en général elles restaient positionnées),

   • appuyer sur la touche "RESET" ,

   • appuyer sur la touche "ZERO MEMORY" ,

2. placer ensuite le paquet de cartes de l'éditeur de lien précédé des deux cartes "LOADER" et suivi dans l'ordre :

• du paquet de cartes du module intermédiaire du programme à construire (résultat de la phase 2 du compilateur)

• du paquet de cartes de la bibliothèque-système contenant les modules intermédiaires des sous-programmes et fonctions du système.

• du paquet de cartes de la bibliothèque-utilisateur contenant les modules intermédiaires des sous-programmes et fonctions de l'utilisateur appelés dans les différents modules intermédiaires. S'il venait à en manquer un, l'éditeur de liens le signalait sur la console KSR 33 et demandait à le placer dans le lecteur de cartes,

3. appuyer sur la touche "LOAD" pour lancer le chargement de l'éditeur de liens

4. appuyer sur la touche "START" pour lancer l'exécution de l'éditeur de liens. La machine commençait alors à travailler. Suivant le nombre de cartes du programme intermédiaire, après un temps de calcul entre 5 et 10 minutes, la machine se mettait à perforer un paquet de cartes, le module exécutable du programme de l'utilisateur.. Un message sur la console KSR 33 nous indiquait que le module exécutable était construit et utilisable suivant la même procédure qui vient d'être décrite.

IV - Mon premier contact avec un assembleur :

          Nous avions chacun un passage par jour. Cette situation nous était à tous assez pesante. De plus, elle était accentuée car il arrivait parfois que, personne n'étant prêt pour tester son programme d'une part et n'ayant pas momentanément d'autres calculs de production à effectuer d'autre part, la machine restât quelques temps sans travailler. Avec mon collègue Genoux, qui en avait déjà quelques notions, nous nous sommes mis à "potasser" l'assembleur de la machine, le SPS. Comme mon chef de service m'avait refusé une petite formation de quatre jours chez IBM pour l'apprendre - trop cher -, et nous avait interdit à tous les deux de l'étudier dans la journée pendant certains temps vides, qu'à cela ne tienne !... je prenais les brochures chaque jour et me formais tout doucettement à la programmation en PSP.... à la maison... Mais dans quel but finalement ?

• tout d'abord dans un but de curiosité. Mon collègue, un peu moins "fana" que moi préférait se consacrer surtout à ses deux projets de vibration et de structure, mais s'y intéressait quand même pas mal.

• cela nous permettait de mieux apréhender la machine pour utiliser le compilateur au mieux en espace mémoire et vitesse d'exécution. Le taux d'expension du compilateur Fortran 2 était de l'ordre de 30 à 35%.

• nous le faisions le plus discrètement possible, cela nous permettait de modifier directement le code-machine des modules exécutables en élaborant des petits "patches" afin d'avoir un peu plus d'un passage par jour pour tester nos programmes. Il faut voir que corriger un "+" en un "-" dans une formule, par exemple, était une modification quasi instantanée aussi bien dans le paquet de cartes que directement en mémoire avec les clés du pupitre.
  
  

  Anecdote :

  notre chef de service qui programmait aussi s'était bien rendu compte que nous passions plusieurs fois dans la journée en test sur la machine. Il avait bien vu notre "petit manège". Il s'en était très fâché et nous avait fortement réprimandé tous les deux.     Mais, quelle ne fut pas ma surprise !... Paradoxalement, il ne put résister, lui, à la tentation de passer aussi plusieurs fois dans la journée en me demandant, à plusieurs reprises, de modifier ses programmes pour ne pas avoir à les recompiler et à les rééditer.... Cela ne l'empêchait pas d'user, par ailleurs, de sa position hiérarchique pour faire des entorses à la régle mais j'imagine qu'il avait quelques scrupules quand même !...

  
  

• cela nous permettait enfin de réécrire des fonctions et/ou certains passages de programmes afin d'en améliorer les performances.

  Enfin de compte, la programmation à l'époque, et cela n'a pas changé tout au moins pour moi, était un jeu de puzzle assez excitant. Comme j'aime bien les puzzles, je pouvais lier l'utile à l'agréable !...

--ooOoo--