# IBM CP-40

CP-40 était un prototype de CP-67, lui-même partie du système, alors révolutionnaire, IBM CP[-67]/CMS ; un système d'exploitation en temps partagé à machine virtuelle et mémoire virtuelle pour les IBM System/360 modèle 67, et l'ancêtre des systèmes de la famille IBM VM. CP-40 pouvait exécuter plusieurs instances de systèmes d'exploitation «clients», en particulier CMS, le Cambridge Monitor System, partie intégrante du même projet. Comme CP-67, CP-40 et la première version de CMS furent développés par l'équipe du centre scientifique de Cambridge (CSC) d'IBM, en étroite collaboration avec les chercheurs du projet MAC au laboratoire Lincoln du MIT. L'utilisation en contexte de production de CP-40/CMS démarra en janvier 1967. CP-40 fonctionnait sur un prototype unique, modifié pour l'occasion, d'IBM System/360 modèle 40.

## Buts du projet

CP-40 était un système de recherche sans visée commerciale. Ses objectifs officiels étaient :
* Fournir des éléments de recherche à l'équipe du System/360 modèle 67 basée à Poughkeepsie, qui explorait le terrain inconnu de concept alors-nouveau de mémoire virtuelle.
* Remplir les besoins en temps partagé du CSC à Cambridge.
Cependant, il y avait aussi une mission non officielle : démontrer la capacité d'IBM à subvenir aux besoins d'utilisateurs de temps partagé comme le MIT. CP-40 (et son successeur) ont atteint ce but, tant du point de vue que social : Ils ont participé à démontrer la faisabilité des machines virtuelles, à établir une norme d'utilisation en temps partagé, et à fonder une industrie des services informatiques à distance. Malheureusement, le projet se retrouva empêtré dans une guerre politique interne à IBM, opposant le temps partagé et le traitement par lots ; et il faillit à rallier les cœurs et les esprits de la communauté académique des sciences informatiques, ce qui eut pour conséquence de les détourner d'IBM au profit de systèmes tels que Multics, UNIX, TENEX, et les différents systèmes d'exploitation DEC. Quoi qu'il en soit, les concepts de virtualisation développés par le projet CP-40 ont porté leurs fruits dans divers domaines, et restent très importants aujourd'hui.

## Fonctionnalités

CP-40 était le premier système d'exploitation à mettre en place la virtualisation complète, c'est-à-dire qu'il fournissait un environnement de machine virtuelle prenant en charge toutes les caractéristiques de son environnement cible (un S/360-40). Ainsi, d'autres systèmes d'exploitation S/360 pouvaient être installés, testés, et utilisé comme s'ils résidaient sur une machine séparée. Le CP-40 était capable de faire fonctionner quatorze machines virtuelles simultanément. Chaque machine virtuelle s'exécutait dans un régime de «gestion de problème» : des instructions privilégiées telles que les opérations d'entrée/sortie provoquaient des exceptions, qui étaient ensuite interceptées par le programme de contrôle et simulées. De manière similaire, les références à des emplacements de mémoire virtuelle non présents dans la mémoire principale provoquaient des erreurs de page, qui étaient, elles-aussi, gérées par le programme de contrôle plutôt que d'être traitées par la machine virtuelle. De plus amples détails ce fonctionnement se trouvent dans CP/CMS (architecture) .
L'architecture de base et l'interface utilisateur de CP-40 ont été reprises dans CP-67/CMS, qui a évolué pour devenir la gamme de systèmes VM d'IBM.

## Plate-forme matérielle

Le modèle 67 n'était pas disponible lors de la mise en place du CP-40, donc un dispositif de mémoire virtuelle spécifique, basé sur une mémoire associative, la «CAT box» (ndt. boîte à chat) a été conçue et construite pour le CSC. Cela impliquait à la fois des modifications matérielles et de microcode d'un Systèm/360 modèle 40. Ces changements ont permis une virtualisation complète de l'architecture System/360. Ce modèle 40 modifié a influencé la conception du futur modèle 67, qui était destiné à répondre aux besoins d'utilisation en temps partagé de la communauté citée plus haut, notamment le projet MAC du MIT et les laboratoires Bell, bien que ces deux sites soient devenus des échecs commerciaux notables d'IBM.
Trois systèmes de mémoire virtuelle différents ont été mis en œuvre par IBM au cours de cette période :
* La «Blaauw Box» (du nom de Gerry Blaauw ), intégrée dans la version initiale du S/360-67
* La «CAT Box» (Cambridge Address Translator : «traducteur d'adresse de Cambridge (ndt)»), ajoutée au S/360-40 du CSC pour exécuter le CP-40
* La «DAT Box» (Dynamic Address Translation : «traduction dynamique d'adresse (ndt)»), annoncée comme une option sur la série S/370 en 1972
Ces systèmes étaient tous différents, mais avaient un air de famille. La CAT box du CP-40 a été une étape clé. Pugh et al. citent un article de l'IEEE sur le matériel de mémoire virtuelle du CP-40, et déclare qu'il était "unique en ce qu'il comprenait une banque de registres de recherche parallèle pour accélérer la traduction d'adresse dynamique. Avec des fonds fournis par Cambridge, les ingénieurs d'IBM [...] ont construit une mémoire associative à 64 registres et l'ont intégrée dans un 360/40. Le résultat unique en son genre a été expédié à Cambridge au début de 1966."
Il est important de noter que, bien que la prise en charge de la virtualisation ait été un objectif explicite pour le modèle 40 modifié du CSC, ce n'était apparemment pas le cas de la version initiale du modèle 67. Le fait que les capacités de virtualisation ont finalement été mises en œuvre dans le 67, et ont ainsi permis le succès de CP-67/CMS, témoigne de la ténacité et de la force de persuasion de l'équipe du CSC.

## CMS sous CP-40

CMS a été construit pour la première fois en 1964 au CSC pour fonctionner comme un système d'exploitation «client» sous CP-40. Le chef de projet du CMS était John Harmon. Bien que n'importe quel système d'exploitation S/360 puisse être exécuté sur une machine virtuelle CP-40, il a été décidé qu'un nouveau système d'exploitation simple, interactif et mono-utilisateur serait la meilleure solution pour fournir des sessions utilisateur interactives en temps partagé. Cela éviterait la complexité et la surcharge dues à l'exécution d'un système multi-utilisateurs comme CTSS. (contrairement à l'OS/MVT-TSO d'IBM et ses successeurs, essentiellement un système d'exploitation à temps partagé fonctionnant comme une seule tâche sous un système de traitement par lots IBM ; Avec CMS, chaque session utilisateur interactive obtient une machine virtuelle privée. )
Jusqu'à septembre 1965, de nombreuses décisions importantes concernant la conception du CMS ont été prises :
* Des commandes intuitives, avec un mode par défaut, et des paramètres non requis dans la mesure du possible (pour faciliter l'utilisation et la formation, et pour minimiser le besoin de supervision).
* Un ensemble de base de commandes et de macros de système de fichiers ; une convention de nommage de fichier simple, basée sur le nom de fichier, le type de fichier et le mode de fichier (mode de fichier = identifiant de disque logique ou minidisk, une forme d' attribution de lettre de lecteur).
* Enregistrements stockés sur des blocs de taille fixe, pouvant être lus ou écrits par numéro d'enregistrement relatif.
* Fichiers pouvant être créés simplement en y écrivant, sans avoir besoin d'opérations spéciales de «création».
* Modes de fichiers par défaut, permettant de rechercher des disques dans un ordre prédéterminé.
Il s'agissait de changements radicaux par rapport à la dénomination complexe des fichiers, au contrôle des tâches (via JCL) et aux autres modalités des systèmes d'exploitation traditionnels d'IBM. (Certains de ces concepts avaient été des objectifs pour les systèmes d'exploitation d'autres fournisseurs, tels que Control Data Corporation et DEC.)
Le système de fichiers CMS, avec sa structure de répertoire «à plat», a été choisi pour sa simplicité. Creasy note : « Cette structure de plusieurs disques, chacun avec un seul répertoire, a été choisie pour être simple mais utile. Les répertoires à plusieurs niveaux, avec des fichiers stockés dans des zones communes, étaient la tendance en matière de conception lorsque nous avons commencé. Nous avons simplifié la conception de ce composant, et d'autres, du CMS afin de réduire la complexité de la mise en œuvre.»
Les applications s'exécutant sous une instance de CMS étaient exécutées dans le même espace d'adressage. Elles accédaient aux services système, tels que le système de fichiers CMS, via une interface de programmation simple au noyau CMS, qui résidait en mémoire basse dans la machine virtuelle CMS. Un ensemble d'appels système était fourni, dont la plupart seraient familiers aux programmeurs CMS (étant donné que les applications s'exécutaient dans la machine virtuelle CMS, elles pouvaient potentiellement mal se comporter, en écrasant des données CMS, en utilisant des instructions privilégiées ou en effectuant d'autres actions susceptibles de bloquer ou de planter la machine virtuelle. Bien sûr, cela ne pouvait pas affecter les autres machines virtuelles, qui étaient toutes isolées les unes des autres ; Elles ne pouvaient pas non plus endommager le programme de contrôle sous-jacent. Contrairement à la plupart des systèmes d'exploitation, les pannes de programme de contrôle provenaient rarement d'erreurs d'application - et étaient donc elles-mêmes relativement rares. )

## Notes historiques

Les notes suivantes fournissent de brèves citations, principalement de Pugh, Varian et Creasy [voir les références], illustrant le contexte du développement de CP-40. Des citations directes plutôt que des paraphrases sont fournies ici, car les points de vue des auteurs colorent leur interprétation. Voir également Historique de CP/CMS pour une contextualisation supplémentaire.
* Genèse du projet CP-40 :
** Rasmussen de CSC se sentait "très dubitatif" à propos du TSS/360 et a décidé que ses ressources CSC disponibles devraient être utilisées pour créer un "système en temps partagé crédible pour le S/360", qui prit le nom de CP-40. Le chef de projet était Robert Creasy, qui avait été un des programmeurs de CTSS.
** Les objectifs du CP-40 comprenaient à la fois la réalisation de recherches (obtention et analyse de données sur les systèmes et les logiciels, y compris l'utilisation de la mémoire associative) et la satisfaction des propres besoins informatiques du CSC via le temps partagé. Varian ajoute : "Le véritable objectif du projet était de construire un système en temps partagé, mais les autres objectifs étaient également réels, et ils ont toujours été mis en avant afin de masquer les aspects "contre-stratégiques" du projet." Creasy décrit ainsi les objectifs du CP/CMS : il devait s'agir d'un " système de temps partagé de deuxième génération pour le système IBM/360 récemment annoncé... [qui pourrait] prendre en charge toutes les activités du centre de Cambridge, y compris des activités aussi diverses que recherche sur le système d'exploitation, développement d'applications et préparation de rapports par des programmeurs, des scientifiques, des secrétaires et des gestionnaires. Peu de temps après sa création, il était pratique pour le système d'être reconnu et soutenu financièrement à l'extérieur du centre comme un outil pour évaluer et tester les performances des systèmes d'exploitation."
** Les recherches de CSC étaient importantes pour IBM, car à l'époque, "on ne savait pas grand-chose sur les systèmes de mémoire virtuelle". Varian cite LW Comeau : "L'engagement [d'IBM] envers la mémoire virtuelle n'était basé sur aucune expérience réussie. . . . Ce qui était effrayant, c'est que personne de ceux qui avaient pris cette direction de mémoire virtuelle chez IBM ne savait pourquoi [le système de mémoire virtuelle contemporain Ferranti] Atlas ne fonctionnait pas." (Comeau a conclu plus tard que l'Atlas avait souffert de thrashing, qui n'avait pas été étudié jusqu'à ce qu'il soit observé sur l'IBM M44/44X et sur le CP-40. )
* Conception CP-40 : Pugh et al. écrivent ceci : « En 1964… IBM Research recommandait l'utilisation des principes de la machine virtuelle aux planificateurs de partage de temps… [qui ont été] repris par l'équipe de Cambridge [CSC], qui voulait, entre autres, un système capable de tester les autres systèmes d'exploitation. Une décision de conception clé, prise par Creasy et Comeau à la fin de 1964, était de baser le CP-40 non seulement sur la mémoire virtuelle mais sur des machines virtuelles (d'abord appelées pseudo-machines, jusqu'à ce que le terme ultérieur soit repris du projet IBM M44/44X, que Creasy décrit comme ayant « des idées similaires mais indépendantes ». Creasy fournit une description claire de la stratégie de virtualisation de CP, basée sur le jeu d'instructions S/360, qui se composait d'instructions "état superviseur" privilégiées distinctes des instructions "état problème" normales : "Chaque programme de machine virtuelle [CP] est en fait exécuté [entièrement] en état problématique. . . . Les instructions privilégiées...[sont] reproduites par CP au sein des machines virtuelles. . . ." En exécutant un système d'exploitation en état de problème, toutes les instructions "problématiques" seraient automatiquement interceptées par le matériel. Cela ne laissait qu'un seul problème principal de virtualisation : les références mémoire. "L'expérience [avec CTSS] ... a suggéré la nécessité pour la relocalisation dynamique des programmes ... de diviser les programmes en morceaux qui pourraient être déplacés vers, hors et à l'intérieur de la mémoire, indépendamment les uns des autres."
* Machines virtuelles CP-40 :
** Les projets de recherche antérieurs impliquant le concept de machine virtuelle, tels que l'IBM M44/44X, n'avaient pas tenté de créer une copie virtuelle exacte d'une machine réelle. Creasy : "[Ils étaient] suffisamment proches... pour prouver que 'suffisamment proches' ne comptait pas."
** Le CP-40 a franchi l'étape audacieuse de la virtualisation complète, en créant quatorze environnements S/360 virtuels, chacun avec une taille fixe de mémoire virtuelle de 256 Ko, un accès mappé aux partitions de disque et un accès spoulé aux périphériques d'enregistrement de l'unité (par exemple, les imprimantes). Comeau : "[Créer une virtualisation complète] a permis le développement simultané de CP et de CMS ; cela nous a permis de mesurer des systèmes non virtuels, OS et DOS, dans un environnement de mémoire virtuelle, et cela a également fourni un haut niveau d'intégrité et de sécurité."
** En plus de révéler la valeur de la virtualisation complète, l'IBM expérimental M44/44X "a implanté l'idée que le concept de machine virtuelle n'est pas nécessairement moins efficace que les approches plus conventionnelles" - une hypothèse de base dans l'architecture CP-40, et qui finalement s'est révélée très fructueuse.
** Le CP-40 prendrait bientôt en charge "jusqu'à une douzaine de machines virtuelles System/360" sous contrôle de terminal [la plupart des sources en indiquent quatorze]. (CP-67 a ensuite "exploité ... la traduction d'adresses ... et augmenté la vitesse ... pour doubler la capacité" du CP-40. )
* CMS sous CP-40 :
** À propos de la décision de séparer CMS et CP, Creasy écrit : "La mise en œuvre de CTSS a illustré la nécessité d'une conception modulaire pour l'évolution du système. Bien qu'un succès en tant que système de production, les interconnexions et les dépendances de la conception de son superviseur ont rendu l'extension et les modifications difficiles. Un concept clé de la conception CP / CMS était la bifurcation de la gestion des ressources informatiques et du support utilisateur. En effet, la conception intégrée [du CTSS] a été divisée entre CP et CMS." La valeur de l'expérience acquise dans le cadre du projet CTSS ne peut être surestimée.
** À propos des premiers CMS, Creasy écrit : Le CMS « fournissait un service à utilisateur unique sans être gêné par les problèmes de partage, d'allocation et de protection ». Les premiers développements du CMS impliquaient de démarrer le CMS sous BPS, un des premiers systèmes de prise en charge de S/360, jusqu'à ce que le CMS soit suffisamment avancé pour démarrer de manière autonome. Finalement, le développement s'est déplacé vers des machines virtuelles sous CP.