Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

16.02.1979 - 

Anwendungsrestriktion durch Maschinenabhängigkeit der Firmware:

Mikroprogrammierung setzt Hardware-Kenntnisse voraus

MÜNCHEN - Die Vorteile der Mikroprogrammierung wurden bisher nahezu ausschließlich von den Universalrechner-Herstellern genutzt - dem Anwender blieb der Zugang zur Firmware verwehrt. Angeregt durch die Thema-der-Woche-Umfrage "Mikroprogrammierung - nur für Spezialisten?" (CW-Nr. 3 vom 19. Januar 1979) berichten Raimund Kölsch und Joachim Flöthe vom Institut für Informatik der Christian-Albrechts-Universität in Kiel über ihre Aktivitäten, die Mikroprogrammierung auch dem Anwender zugänglich zu machen. Hier ihr Beitrag:

Mit der Entwicklung immer leistungsfähigerer Rechner wächst die Komplexität ihrer Steuerwerke. Selbst kleine Modifizierungen im Befehlsvorrat können Änderungen großer Teile der "Verdrahtung", nötig machen. In diesem Zusammenhang ist das grundlegende Konzept von Wilkes zu sehen, der den Begriff "microprogrammed control" einführte. Er sah Mikroprogrammierung als "a systematic and orderly approach to designing the control selection of a computer". Dieses Konzept wurde erstmals 1958 in dem Computer EDSAC realisiert. Es bedeutet. daß ein Maschinenbefehl nicht festverdrahtet ist, sondern durch eine Folge von Mikrobefehlen interpretiert wird, die in einem speziellen, sehr schnellen Read-Only-Memory (ROM) abgelegt sind. Diese Mikrobefehle können wiederum aus mehreren, parallel auszuführenden Mikrooperationen bestehen. Eine weitere Verbreitung dieses Konzepts scheiterte damals an den hohen Kosten für den "control storage".

Anfang der 60er Jahre setzte IBM als erster großer Hersteller die Mikroprogrammierung in seinem System 360 ein. Das Hauptanwendungsgebiet der Mikroprogrammierung in jener Zeit blieb neben der Realisierung der eigenen Maschinenbefehle die Emulation von Vorgänger- oder Mitbewerbermodellen.

Durch die große Flexibilität auf der Mikroebene ist es möglich, Funktionen für spezielle Anwendungen durch Mikroprogramme zu implementieren. Von der Herstellerseite wurden so im Laufe der Zeit Teile der Betriebssysteme in die Mikroprogrammebene

(Firmware) verlagert. Ebenso wurden höhere Programmiersprachen unterstützt.

Die technologische Entwicklung brachte vor einiger Zeit beschreibbare Mikroprogrammspeicher zu erschwinglichen Preisen hervor. Da durch die Mikroprogrammierung beträchtliche Laufzeitverbesserungen zu erzielen sind, tauchte auf der Benutzerseite der Wunsch auf, die Vorteile der Mikroprogrammierung zu nutzen, und die Rechner wechselnden Anforderungen anzupassen. Mikroprogrammpakete sollen dabei auf Wunsch in den Mikroprogrammspeicher geladen werden, um Klassen von Programmen zu unterstützen (dynamische Mikroprogrammierung).

Am Institut für Informatik der Universität Kiel haben wir uns dem Problem gewidmet, die Mikroprogrammierung auch Anwendern zugänglich zu machen. Speziell untersuchen wir die Möglichkeit der Anwender-Mkroprogrammierung auf dem Siemens System 7.000.

Das von uns konzipierte und teilweise implementierte System läßt sich in drei Gruppen unterteilen:

- Erstellung von Mikroprogrammen,

- Systemeinbettung,

- Anschluß von Mikrocode an Hochsprachenprogramme.

Die Hardware bleibt dem Programmierer verborgen

Es wurde eine Mikro-Assemblersprache definiert und der zugehörige Assembler implementiert. Damit ist es möglich, Mikroprogramme in symbolischer Form zu erstellen. Für die Programmierung in dieser Sprache sind nach unserer Auffassung allerdings noch zu viele spezielle Kenntnisse über die Hardware erforderlich. Es wird daher an der Entwicklung einer höheren Mikroprogrammiersprache gearbeitet, die dem Anwender hohen Komfort bieten soll.

Es werden Kontrollstrukturen einer modernen Programmiersprache zur Verfügung stehen und die Hardware wird dem Programmierer weitgehend verborgen bleiben. Der Sprachumfang wird lediglich Zugriffe auf programmbezogene Daten erlauben. Ohne solche Einschränkungen ist eine dynamische Mikroprogrammierung in einem Timesharing-System nicht denkbar. Beim Übersetzungsprozeß wird für eine maximale Parallelität des erzeugten Codes gesorgt, wodurch dem Programmierer eine weitere Aufgabe abgenommen wird.

Da Mikroprogramme im allgemeinen nur im "Stand-alone"-Betrieb getestet werden können, muß ein weiteres Hilfsmittel zur Verfügung gestellt werden, um diese Test-Phase möglichst kurz zu gestalten.

Diese Aufgabe übernimmt ein Simulator, mit dessen Hilfe Mikroprogramme im Timesharing ausgetestet werden können.

Kontroll-Mechanismen auf Firmware-Ebene unterlaufen

Da auf der Firmware-Ebene fast alle Kontroll-Mechanismen des Systems unterlaufen werden können, ist es gerade in einem Timesharing-System wichtig, den sicheren Ablauf der Mikroprogramme zu garantieren. Diese Aufgabe wird weitgehend von einem "WCM-Manager" (WCM = Writable Control Memory) übernommen. Er hat dafür zu sorgen, daß die Mikroprogramme bei Bedarf in den Kontrollspeicher (WCM) geladen werden. Es dürfen allerdings nur solche Programme dorthin gelangen, die gewissen Sicherheitsanforderungen genügen. Diese sind bei der Integration in das System (Übernahme in eine Bibliothek) zu prüfen.

Es wurde die Möglichkeit geschaffen, Mikroprogramme ähnlich wie externe Prozeduren von Pascal aus aufzurufen. Hierdurch wird eine vertikale Verlagerung von Programmfunktionen in den Mikrocode ermöglicht. Diese kann als Ausdehnung des Prozesses der schrittweisen Verfeinerung über die Software-Firmware-Grenze hinaus angesehen werden. Man kann dadurch ein Programm "tunen", indem man besonders zeitaufwendige Teile mikroprogrammiert.

Große Aufmerksamkeit wird in der nächsten Zeit der Entwicklung höherer Mikroprogrammiersprachen gewidmet werden müssen. Wünschenswert, aber verständlicherweise mit erheblichen Schwierigkeiten verbunden, ist eine maschinenunabhängige Mikroprogrammiersprache.

Ebenfalls ist an die Entwicklung von Hybrid-Compilern zu denken, die gewisse Teile des Programms in Mikrocode übersetzen, während für den Rest Maschinencode erzeugt wird. Wo Mikrocode zu erzeugen ist, entscheidet entweder der Programmierer, oder der Compiler, indem er die er die zeitaufwendigen Programmteile wie innere Schleifen oder komplizierte Zugriffe selbst bestimmt.