Feinsinnig bemerkt IBM, daß Kenntnisse über den internen Datenfluß eines Rechners "auch von einem erfahrenen Anwendungsprogrammierer nicht gefordert" und deshalb in einer modernen Maschinenarchitektur "nicht vorausgesetzt werden" dürfen. Diese Feststellung gehört zu einem Software-strategischen Puzzle, das Antwort auf die Frage liefern soll: Bringt es Vorteile, Teile des Betriebssystems in Mikrocode auszuführen? Die Software-Spezialisten des Marktführers vertreten in dieser Frage einen Pro-domo-Standpunkt: "Bei sehr gleichmäßigem Anwendungsprofil und niedrigen Anforderungen an Portabilität wird es vorteilhaft sein, mehr typische Betriebssystemfunktionen im Mikrocode auszuführen." Indes läge es, so deutet IBM an, bei den Anwendern, sich diese Jacke anzuziehen oder nicht. Der folgende Beitrage untersucht den gegenwärtigen Stand der Betriebssystem-Technik und weist auf Entwicklungstendenzen bei den Grundfunktionen der Betriebssysteme hin.
"Es hat keinen Sinn, den Mikrocode dem Benutzer direkt zugänglich zu machen"
Das Betriebssystem ist nicht der unterste Bereich codierter Instruktionen im System. Zwischen der Maschinenarchitektur und den Schaltkreisen findet man heute meist noch eine oder mehrere Ebenen von Mikroinstruktionen, den Mikrocode. Ein Mikrocode ist aufgrund der starken Integration der Schaltkreise wesentlich schneller zu entwickeln als die Schaltkreise selbst, so daß man es vor allem bei langsameren Modellen vorzieht, mehr Mikrocode und weniger Schaltkreise vorzusehen. Der Mikrocode ist wegen seiner Abhängigkeit von der darunter liegenden Hardware innerhalb einer Rechnerserie modellabhängig. Deshalb gibt es für ihn keine Architektur, und deshalb hat es auch keinen Sinn, ihn dem Anwender direkt zugänglich zu machen.
Der Mikrocode ist meist in einem getrennten Speicher, dem Steuerspeicher, untergebracht; Teile, wie etwa Konfigurationstabellen, können auch in den Hauptspeicher geladen werden.
Die Software hat keinen direkten Zugriff zum Mikrocode, so daß der Anwender den Mikrocode weder absichtlich noch unabsichtlich zerstören kann; der Mikrocode ist somit ein automatisch geschützter Code. Aus diesem Grund kann man auch auf die Prüfung der Operanden im Mikrocode, die zu einer wesentlichen Verringerung der Systemgeschwindigkeit führen würde, verzichten. Im Gegensatz zu Mikroinstruktionen können Mikroinstruktionen damit nicht zu Programmfehlerbedingungen führen. Wäre der Mikrocode einem Benutzer direkt zugänglich, so könnte dieser die Maschine unter Umständen in einen undefinierten Zustand bringen.
"Der Mikrocode ist aufgrund seiner Abgrenzung gegen den Benutzer unzerstörbar"
Kennzeichnend ist auch die starke Bezugnahme auf interne Schaltvorgänge in Mikroinstruktionen. Derartige Kenntnisse über den internen Datenfluß eines Rechners können auch von einem erfahrenen Anwendungsprogrammierer nicht gefordert werden und dürfen deshalb in einer modernen Maschinenarchitektur nicht vorausgesetzt werden.
Zusammenfassend läßt sich sagen, daß der Unterschied zwischen Mikrocode und Mikrocode weniger prinzipieller als gradueller Natur ist. Mikrocode ist noch anwendungsferner, aber aufgrund seiner Abgrenzung gegen den Benutzer unzerstörbar. Außerdem ist der Mikrocode modellabhängig.
Bringt es Vorteile, Teile des Betriebssystems in Mikrocode auszuführen?
Bezogen auf das Schichtenmodell der Systemsoftware (Grafik) bedeutet diese Frage: Soll man die Architektur zum Zweck der Optimierung zwischen Betriebssystem und Mikrocode ändern? Die Beantwortung dieser Frage hängt stark von dem Anwendungsprofil des entsprechenden Systems ab. Die anwendungsorientierten Instruktionen dürfen von einer derartigen Verschiebung der Architektur wegen der geforderten Programmportabilität nicht berührt werden. Im Gegensatz dazu ist bei den privilegierten Instruktionen der Freiheitsgrad für Architekturänderungen größer, solange sie keine Änderungen bei den Ein- und Ausgabegeräten nach sich ziehen. Das gleiche gilt für die Entwicklung zusätzlicher Instruktionen. Dieser Freiraum wird häufig genutzt, um sogenannte "Hardware-Assists" einzuführen. "Hardware-Assists" sind bestimmte, in den Mikrocode verlegte Funktionen der Systemsoftware, mit denen sich beispielsweise der Systemdurchfluß in einem Rechnermodell verbessern läßt.
Dem Programm erscheinen solche "Assists", wie in der Hardware ausgeführt. Der Umfang der "Assists" wird durch den Ablauf asynchroner Unterbrechungen zeitlich begrenzt, da zum Zeitpunkt einer solchen Unterbrechung ein der Maschinenarchitektur entsprechender wohl definierter Zustand im System bestehen muß.
Die Entscheidung zwischen Betriebssystem und Mikrocode ist letztlich eine Architekturentscheidung, die abhängig ist von
- dem Detail, das der Anwendungsprogrammierer zu seiner Verfügung haben möchte, beispielsweise um Prozeßsteuerungsprogramme zu schreiben, und
- der Flexibilität in der Hardware- und Software-Konfiguration, die entsprechend den unterschiedlichen Anwendungsprofilen benötigt wird.
Je mehr Flexibilität erforderlich ist umso mehr Parameter müssen dem Anwender zur Verfügung stehen. Diese können aber am besten in dem freien Raum oberhalb der Maschinenarchitektur neuen Anforderungen angepaßt werden. Bei sehr gleichmäßigem Anwendungsprofil und niedrigen Anforderungen an Portabilität hingegen wird es vorteilhaft sein, mehr typische Betriebssystemfunktionen im Mikrocode auszuführen.
"Größerer Aufwand wird in die bessere Benutzbarkeit der Betriebssysteme
zu stecken sein"
Aus dem bis hierher Gesagten läßt sich eine Aufgabenverteilung zwischen den verschiedenen Schichten eines Datenverarbeitungssystems herleiten. Die Hardware bietet die Basisfunktionen. Zwischen dem Anteil an Hardware und Mikrocode wird aufgrund der gewünschten Leistung und der Entwicklungskosten eines Rechnermodells entschieden. Der Mikrocode seinerseits stellt dem Benutzer die Maschinenarchitektur zur Verfügung, diese wiederum wird durch die Anforderungen der Anwendungsprogrammierung sowie der gewünschten Konfigurierbarkeit und Flexibilität des Systems bestimmt. Die Betriebssysteme schließlich schaffen eine gewisse Unabhängigkeit der Anwendungen von der Maschinenarchitektur; sie vermitteln und optimieren die benötigten Betriebsmittel zwischen den Anwendungen und erleichtern durch sprachliche Hilfsmittel die Anwendungsprogrammierung selbst.
Sicherlich wird man in Zukunft die Schnittstelle zwischen den Grundfunktionen und der Maschine (das heißt der Maschinenarchitektur) oder, genauer gesagt, die Schnittstelle zwischen Betriebssystem und Mikrocode weiter optimieren. Größerer Aufwand wird in die bessere Benutzbarkeit der Betriebssysteme zu stecken sein. Das bedeutet mehr automatische Bereitstellung von Diensten und dafür weniger Parameter. Es bedeutet auch mehr Adaptionsfähigkeit der Betriebssysteme, das heißt eine einfachere Generierung und damit eine leichtere Installation. Ebenso wie eine bessere Optimierung zwischen den Grundfunktionen der Betriebssysteme und dem Mikrocode wird man auch eine bessere Optimierung zwischen Grundfunktionen und den auf ihr residierenden Untersystemen anstreben. Man wird also versuchen, mehr Grundfunktionen der Untersysteme in die Basis der Betriebssysteme oder auch in den Mikrocode aufzunehmen.
*Der Beitrag beruht auf einem Vortrag, der auf einem Journalisten-Seminar des IBM-Laboratoriums am 7. März 1979 in Böblingen gehalten wurde.