CP-40 était un prototype de CP-67, lui-même partie du système, , 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 . 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'à , 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."