IBM CP-40 - IBM CP-40

CP-40

Deweloper	IBM Cambridge Scientific Center (CSC)
Rodzina systemów operacyjnych	CP / CMS
Stan pracy	Historyczny
Pierwsze wydanie	styczeń 1967 ; 54 lata temu ( 1967-01 )
Cel marketingowy	IBM mainframe komputerów
Dostępne w	język angielski
Platformy	Unikalny, specjalnie zmodyfikowany IBM System / 360 Model 40
Domyślny interfejs użytkownika	Interfejs linii komend
Licencja	Prawnie zastrzeżony
zastąpiony przez	CP-67

CP-40 był prekursorem badań do CP-67 , która z kolei była częścią ówczesnego rewolucyjnej IBM CP [-67] / CMS - maszynę wirtualną / pamięć wirtualna time-sharing system operacyjny dla System / 360, IBM model 67 , i rodzic rodziny maszyn wirtualnych IBM . CP-40 uruchamiał wiele instancji klienckich systemów operacyjnych – w szczególności CMS , Cambridge Monitor System , zbudowany w ramach tego samego wysiłku. Podobnie jak CP-67, CP-40 i pierwsza wersja CMS zostały opracowane przez personel Cambridge Scientific Center (CSC) IBM , ściśle współpracując z naukowcami z MIT w Project MAC i Lincoln Laboratory . Produkcja CP-40 / CMS rozpoczęła się w styczniu 1967 roku. CP-40 działał na unikalnym, specjalnie zmodyfikowanym IBM System / 360 Model 40 .

Cele projektu

CP-40 był jednorazowym systemem badawczym. Zadeklarowane cele to:

• Przekaż dane badawcze zespołowi System/360 Model 67 pracującym w Poughkeepsie, który wkraczał na nowy teren dzięki niesprawdzonej jeszcze koncepcji pamięci wirtualnej.
• Obsługuj wymagania CSC dotyczące podziału czasu w Cambridge.

Jednak była też ważna nieoficjalna misja: zademonstrować zaangażowanie IBM we wspieranie użytkowników korzystających ze współdzielenia czasu, takich jak MIT. CP-40 (i jego następca) osiągnęły swoje cele z technicznego i społecznego punktu widzenia – pomogły udowodnić rentowność maszyn wirtualnych, stworzyć kulturę współdzielenia czasu użytkowników oraz uruchomić branżę zdalnych usług komputerowych. Jednak projekt został uwikłany w wewnętrzną wojnę polityczną IBM o podział czasu w porównaniu z przetwarzaniem wsadowym; i nie udało się zdobyć serc i umysłów akademickiej społeczności informatycznej, która ostatecznie odwróciła się od IBM na rzecz systemów takich jak Multics , UNIX , TENEX i różnych systemów operacyjnych DEC . Ostatecznie jednak koncepcje wirtualizacji opracowane w ramach projektu CP-40 zaowocowały w różnych obszarach i pozostają ważne do dziś.

funkcje

CP-40 był pierwszym systemem operacyjnym, który zaimplementował pełną wirtualizację, tj. zapewniał środowisko maszyny wirtualnej obsługujące wszystkie aspekty docelowego systemu komputerowego (S/360-40), tak aby można było instalować, testować inne systemy operacyjne S/360 , i używany jak na samodzielnym komputerze. CP-40 obsługiwał czternaście jednoczesnych maszyn wirtualnych. Każda maszyna wirtualna działała w „stanie problemowym” – uprzywilejowane instrukcje, takie jak operacje we/wy, powodowały wyjątki, które następnie były przechwytywane przez program sterujący i symulowane. Podobnie odwołania do lokalizacji pamięci wirtualnej nieobecnych w pamięci głównej powodują błędy stron , które ponownie były obsługiwane przez program sterujący, a nie odzwierciedlane na maszynie wirtualnej. Więcej szczegółów na temat tej implementacji można znaleźć w CP/CMS (architektura) .

Podstawowa architektura i interfejs użytkownika CP-40 zostały przeniesione do CP-67/CMS , który ewoluował, aby stać się obecną linią produktów VM IBM.

Platforma sprzętowa

Model 67 nie był dostępny dla CP-40 budynku, więc zwyczaj wirtualne urządzenie pamięci oparty na pamięci asocjacyjnej (zwanej dalej „kuwety”) został zaprojektowany i zbudowany przez CSC. Wiązało się to zarówno ze zmianami sprzętowymi, jak i mikrokodowymi w specjalnie zmodyfikowanym Systemie/360 Model 40. Zmiany te dały jednostce technologię potrzebną do pełnej wirtualizacji sprzętu System/360. Ten zmodyfikowany Model 40 wpłynął na projekt nadchodzącego Modelu 67, który miał zaspokoić potrzeby tej samej społeczności użytkowników korzystających ze współdzielenia czasu (zwłaszcza Project MAC i Bell Laboratories firmy MIT – choć obie te strony stały się znaczącymi niepowodzeniami sprzedaży IBM).

W tym okresie firma IBM wdrożyła trzy różne systemy pamięci wirtualnej:

• „Blaauw Box” (nazwany na cześć Gerry Blaauw ), część oryginalnego projektu S / 360-67
• "CAT Box" (Cambridge Address Translator), dodany do S/360-40 CSC w celu uruchomienia CP-40
• „DAT Box” (Dynamic Address Translation), ogłoszony jako dodatek do serii S/370 w 1972 r

Wszystkie te systemy były różne, ale nosiły podobieństwo rodzinne. Skrzynia CAT CP-40 była kluczowym kamieniem milowym. Pugh i in. zacytuj artykuł IEEE o sprzęcie pamięci wirtualnej CP-40 i stwierdza, że ​​był „wyjątkowy, ponieważ zawierał bank rejestrów wyszukiwania równoległego, aby przyspieszyć dynamiczną translację adresów. Z funduszami dostarczonymi przez Cambridge, inżyniera IBM... zbudował 64-rejestrową pamięć asocjacyjną i zintegrował ją z pamięcią 360/40. Jedyny w swoim rodzaju wynik został wysłany do Cambridge na początku 1966 roku”.

Należy zauważyć, że chociaż obsługa wirtualizacji była wyraźnym celem zmodyfikowanego Modelu 40 firmy CSC, najwyraźniej nie dotyczyło to oryginalnego projektu Modelu 67. Fakt, że możliwości wirtualizacji zostały ostatecznie wdrożone w roku -67, a tym samym umożliwiły sukces CP-67/CMS , przemawia za wytrwałością i przekonywaniem zespołu CSC.

CMS pod CP-40

CMS został po raz pierwszy zbudowany w 1964 roku w CSC, aby działać jako „kliencki” system operacyjny pod kontrolą CP-40. Liderem projektu CMS był John Harmon. Chociaż każdy system operacyjny S/360 można uruchomić na maszynie wirtualnej CP-40, zdecydowano, że nowy, prosty, interaktywny system operacyjny dla jednego użytkownika będzie najlepszy do obsługi użytkowników korzystających z interaktywnego współdzielenia czasu. Pozwoliłoby to uniknąć złożoności i kosztów związanych z obsługą systemu wielu użytkowników, takiego jak CTSS . (Porównaj to z systemem OS/MVT-TSO firmy IBM i jego następcami – zasadniczo systemem operacyjnym z podziałem czasu działającym jako pojedyncze zadanie w wsadowym systemie operacyjnym IBM. Dzięki CMS każdy interaktywny użytkownik otrzymuje prywatną maszynę wirtualną.)

Do września 1965 r. podjęto już wiele ważnych decyzji projektowych CMS:

• Przyjazne dla użytkownika polecenia, w miarę możliwości z domyślnymi parametrami, które nie są wymagane (dla łatwości użytkowania i szkolenia oraz w celu zminimalizowania wymagań dotyczących kontroli pracy)
• Podstawowy zestaw poleceń i makr systemu plików; prosta konwencja nazewnictwa plików, oparta na nazwie pliku, typie pliku i trybie pliku (filemode = identyfikator dysku logicznego lub minidysk , forma przypisania litery dysku )
• Rekordy mapowane do bloków o stałym rozmiarze, które mogą być odczytywane lub zapisywane według względnego numeru rekordu
• Pliki, które można utworzyć po prostu pisząc do nich, bez konieczności wykonywania specjalnych operacji „tworzenia”
• Domyślne tryby plików, umożliwiające przeszukiwanie dysków w ustalonej kolejności

Były to radykalne odejścia od trudnych nazewnictwa plików, kontroli zadań (poprzez JCL) i innych wymagań „prawdziwych” systemów operacyjnych IBM. (Niektóre z tych koncepcji były celami dla systemów operacyjnych innych dostawców, takich jak Control Data Corporation i DEC ).

Projekt systemu plików CMS, z płaską strukturą katalogów , był celowo prosty. Creasy notes: „Ta struktura wielu dysków, każdy z jednym katalogiem, została wybrana jako prosta, ale użyteczna. Wielopoziomowe katalogi połączone z plikami przechowywanymi we wspólnych obszarach były trendem projektowym, kiedy zaczynaliśmy. Uprościliśmy projekt tego i innych komponentów CMS w celu zmniejszenia złożoności wdrożenia."

Programy aplikacyjne działające w systemie CMS działają w tej samej przestrzeni adresowej. Uzyskali dostęp do usług systemowych, takich jak system plików CMS, poprzez prosty interfejs programistyczny do jądra CMS , który znajdował się w małej pamięci w maszynie wirtualnej CMS. Zapewniono różne wywołania systemowe, z których większość byłaby znana obecnym programistom CMS. (Ponieważ aplikacje działały na maszynie wirtualnej CMS, mogły potencjalnie źle się zachowywać, nadpisując dane CMS, używając uprzywilejowanych instrukcji lub podejmując inne działania, które mogłyby przejąć lub zawiesić maszynę wirtualną. Oczywiście nie wpłynęłoby to na inne maszyny wirtualne, które wszystkie były wzajemnie izolowane; ani nie mogły uszkodzić podstawowego programu sterującego. W przeciwieństwie do większości systemów operacyjnych, awarie CP rzadko wynikały z błędów aplikacji – i dlatego same były stosunkowo rzadkie.)

Notatki historyczne

Poniższe uwagi zawierają krótkie cytaty, głównie z Pugh, Varian i Creasy [patrz odnośniki], ilustrujące kontekst rozwoju CP-40. Podano tu raczej bezpośrednie cytaty niż parafrazy, ponieważ perspektywy autorów zabarwiają ich interpretacje. Zobacz także Historia CP/CMS, aby uzyskać dodatkowy kontekst.

• Geneza projektu CP-40:
  • Rasmussen z CSC czuł się „bardzo niepewny” co do TSS/360 i zdecydował, że jego bezczynne zasoby CSC powinny zostać wykorzystane do stworzenia „wiarygodnego systemu podziału czasu dla S/360”, który stał się znany jako CP-40. Liderem projektu był Robert Creasy, który wcześniej był programistą CTSS .
  • Cele CP-40 obejmowały zarówno prowadzenie badań (pozyskiwanie i analizowanie danych o systemach i oprogramowaniu, w tym wykorzystanie pamięci asocjacyjnej), jak i spełnianie własnych wymagań obliczeniowych CSC poprzez współdzielenie czasu. Varian dodaje: „Prawdziwym celem projektu było zbudowanie systemu podziału czasu, ale inne cele też były prawdziwe i zawsze podkreślano je, aby ukryć „kontrstrategiczne” aspekty projektu”. Creasy tak opisuje cele CP/CMS: Miał to być „system z podziałem czasu drugiej generacji dla nowo ogłoszonego IBM System/360… [który] wspierałby wszystkie działania centrum Cambridge, w tym tak różnorodne działania, jak badania systemów operacyjnych, tworzenie aplikacji i przygotowywanie raportów przez programistów, naukowców, sekretarki i menedżerów.Wkrótce po jego powstaniu wygodnie było, aby system został rozpoznany i wspierany finansowo spoza centrum jako narzędzie do oceny i testowania wydajność systemów operacyjnych."
  • Badania CSC były ważne dla IBM, ponieważ w tamtym czasie „niewiele było wiadomo o systemach pamięci wirtualnej”. Varian cytuje LW Comeau: „Zaangażowanie [IBM] w pamięć wirtualną było poparte brakiem udanego doświadczenia… Przerażające było to, że nikt, kto wyznaczał ten kierunek pamięci wirtualnej w IBM, nie wiedział, dlaczego [współczesny system pamięci wirtualnej Ferranti] Atlas nie nie działa ”. (Comeau później doszedł do wniosku, że Atlas cierpiał z powodu thrashingu , którego nie badano, dopóki nie zaobserwowano go na IBM M44/44X i na CP-40.)
• Projekt CP-40: Pugh i in. piszą, że: „W 1964 roku… IBM Research rekomendował wykorzystanie zasad maszyny wirtualnej planistom z podziałem czasu… [które] zostały odebrane przez zespół Cambridge [CSC], który chciał, między innymi, system zdolny do testowania systemów operacyjnych." Kluczową decyzją projektową, podjętą przez Creasy i Comeau pod koniec 1964 roku, było oparcie CP-40 nie tylko na pamięci wirtualnej, ale na maszynach wirtualnych (początkowo nazywanych pseudo-maszynami , aż do późniejszego przejęcia z IBM M44 / Projekt 44X – który Creasy opisuje jako „podobne, ale niezależne pomysły”. Creasy zapewnia jasny opis strategii wirtualizacji CP, opartej na zestawie instrukcji S/360 , który składał się z uprzywilejowanych instrukcji „stanu nadzorcy” różniących się od normalnego „stanu problemu” instrukcje: "Każdy program maszyny wirtualnej [CP] jest faktycznie wykonywany [w całości] w stanie problemowym.... Uprzywilejowane instrukcje... [są] odtwarzane przez CP na maszynach wirtualnych..." Przez uruchomienie systemu operacyjnego w stanie problemowym , wszystkie "podchwytliwe" instrukcje byłyby automatycznie przechwytywane przez sprzęt. Pozostał tylko jeden główny problem wirtualizacji: odwołania do pamięci. "Doświadczenie [z CTSS]... sugerowało potrzebę dynamicznej relokacji programów... aby rozbić programy na kawałki który mógłby? być przenoszone do, z i wewnątrz pamięci niezależnie od siebie.”
• Maszyny wirtualne CP-40:
  • Wcześniejsze projekty badawcze obejmujące koncepcję maszyny wirtualnej, takie jak IBM M44 / 44X, nie miały na celu stworzenia dokładnej wirtualnej kopii prawdziwej maszyny. Creasy: „[Byli] wystarczająco blisko… aby udowodnić, że „wystarczająco blisko” się nie liczy”.
  • CP-40 podjął odważny krok w kierunku pełnej wirtualizacji , tworząc czternaście wirtualnych środowisk S/360, każde ze stałym rozmiarem pamięci wirtualnej 256K, mapowanym dostępem do partycji dyskowych i buforowanym dostępem do urządzeń rejestrujących jednostki (np. drukarek). Comeau: „[Tworzenie pełnej wirtualizacji] pozwoliło na równoczesny rozwój CP i CMS; pozwoliło nam zmierzyć systemy niewirtualne, OS i DOS, w środowisku pamięci wirtualnej, a także zapewniło wysoki poziom integralności i bezpieczeństwa”.
  • Oprócz ujawnienia wartości pełnej wirtualizacji, eksperymentalny IBM M44/44X „zaszczepił ideę, że koncepcja maszyny wirtualnej niekoniecznie jest mniej wydajna niż bardziej konwencjonalne podejścia” – podstawowe założenie w architekturze CP-40, które ostatecznie okazał się bardzo udany.
  • CP-40 wkrótce będzie obsługiwał „do tuzina wirtualnych maszyn System/360” pod kontrolą terminala [większość źródeł podaje czternaście]. (CP-67 później „wykorzystał… translację adresów… i zwiększono prędkość… w celu podwojenia pojemności” CP-40.)
• CMS pod CP-40:

• O decyzji o rozdzieleniu CMS i CP, Creasy pisze: „Wdrożenie CTSS zilustrowało konieczność projektowania modułowego dla ewolucji systemu. Chociaż system produkcyjny okazał się sukcesem, połączenia i zależności jego projektu nadzorczego utrudniały rozbudowę i zmianę. Koncepcja projektu CP/CMS polegała na rozwidleniu zarządzania zasobami komputera i obsługi użytkowników. W efekcie, zintegrowany projekt [CTSS] został podzielony na CP i CMS." Wartość doświadczenia zdobytego w projekcie CTSS jest nie do przecenienia.

• O wczesnym CMS, Creasy pisze: CMS „zapewnił usługi dla jednego użytkownika, nieobciążone problemami współdzielenia, alokacji i ochrony”. Wczesny rozwój CMS obejmował uruchamianie CMS pod BPS , wczesnym systemem obsługi S/360, dopóki CMS nie był wystarczająco daleko, aby uruchomić samodzielny system. Ostatecznie rozwój został przeniesiony na maszyny wirtualne w ramach CP.

Zobacz też

• CP[-67]/CMS : szeroko stosowany następca CP-40 i prekursor systemów VM IBM
• Cambridge Scientific Center , gdzie zbudowano CP-40 i CP / CMS
• IBM M44/44X , współczesny eksperymentalny system przywoławczy
• Historia CP/CMS , przegląd wydarzeń i zagadnień prowadzących do powstania CP-40
• Ewolucja systemu z podziałem czasu

Bibliografia

Dalsza lektura

Drzewo rodzinne