Für viele Mikroprozessoren sind nur Makroassembler verfügbar. Betriebssysteme, Dienstprogramme und Testhilfen werden hingegen - wenn überhaupt - nur in einer minimalen Ausbaustufe angeboten.

Die Gründe für diesen wenig befriedigenden Zustand sind sehr unterschiedlich:

- Mikroprozessoren werden als Bauelemente vertrieben. Die Halbleiterhersteller sind nur in Ausnahmefällen bereit, für Systemsoftware zu investieren.

- Als Programmspeicher werden meist Lesespeicher (ROM = read only memory, PROM = programmable ROM, EPROM = erasable PROM) verwandt. Ihr Inhalt (Programm) muß entweder vor ihrer Fertigung (ROM) oder mit Hilfe spezieller Hardware (PROM, EPROM) geladen werden. Dadurch werden Testarbeiten und Systemepflege wesentlich behindert und verteuert. Für den Test müssen deshalb sogenannte "Entwicklungssysteme" eingesetzt werden.

- Die Zielsysteme bieten meist nicht die für den Software-Test erforderliche Peripherie. Cross-Assembler und Simulatoren oder wiederum Entwicklungssysteme ermöglichen diese Arbeiten.

- Objektprogramme sind oft auch für Systeme, die den gleichen Mikroprozessor als Basis benutzen, nicht kompatibel.

- Zusätzlich werden oft auch "spezielle Betriebssysteme" (besser: Real-Time Executives) benötigt, die für die jeweilige Anwendung maßgeschneidert werden müssen.

- In diesem Zusammenhang muß erwähnt werden, daß für einige Prozessoren Implementierungssprachen (zum Beispiel PL/M oder PL/M-Derivate) oder Compiler für BASIC, FORTRAN und (Subset)-COBOL angeboten werden. Während sich Implementierungssprachen für einige Anwendungsgebiete durchsetzen, werden anweisungsorientierte höhere Programmiersprachen für Aufgaben eingesetzt, die für universelle DV-Systeme typisch sind.

Die Software-Portabilität (Wiederverwendung von Quellprogrammen) spielt zur Zeit für spezielle DV-Systeme (dedicated systems) eine untergeordnete Rolle. Dagegen gewinnt die Wiederverwendung abgeschlossener Teilsysteme Hardware und Software) rasch an Bedeutung. Erwähnt werden muß hier, daß solche Teilsysteme wie Bildschirm- oder Terminalsteuerungen nur wenige KB benötigen. Diese Beschränkung erhöht jedoch die Chance für eine Wiederverwendung des Teilsystems ohne Änderungen und reduziert dadurch den Endpreis.

Compiler kontra Programmgeneratoren

Nicht alIein die verwirrende Vielfalt der AssembIer-Mnemonik für Mikroprozessoren, sondern auch das Streben, die Programmierung weniger fehIeranfällig zu gestalten, führt zur Entwicklung möglichst komfortabler ImpIementierungssprachen. Die AnzahI der bereits jetzt angebotenen knapp 100 Typen von Mikroprozessoren wird ständig durch neue Prozessoren vergrößert. Hinzu kommen die kundenspezifischen Prozessoren. Die Entwicklung der Controller verläuft in der gleichen Weise. Abgesehen von dem finanziellen Aufwand besteht keine realistische Chance, Ieistungsfähige, fehlerfreie Compiler einschließlich der erforderliche Testhilfen fristgerecht bereitzustellen.

Ein weiteres Problem stellt die Programmierung (oder besser: die Anpassung) von Teilsystemen an die jeweilige Anwendung dar. Einerseits werden beim Einsatz konventioneller Verfahren mehr Hardware- und Softwarekenntnisse gefordert. Andererseits scheidet der Einsatz von Spezialisten spätestens während der Systempflege aus Kostengründen aus.

Einen Ausweg aus dieser Sackgasse bietet möglicherweise die bisher recht stiefmütterlich behandelten Formularsprachen. Diese bestehen aus Fragebogen. Die Antworten werden von einem Programmgenerator am Erzeugung von Quell- oder Maschinenprogrammen ausgewertet. Im Gegensatz zu anweisungsorientierten höheren Programmiersprachen ähnlich wie Spezialsprachen nur für relativ eng begrenzte Anwendungsgebiete eingesetzt werden. Andererseits sind sie wesentlich flexibler und effizienter einsetzbar als Programmpakete.

Der Grund für den allgemein geringen Erfolg von Programmgeneratoren in der Vergangenheit ist primär darin begründet, daß die relativ hohen Investitionen von Herstellern geleistet wurden, die den Vertrieb ihrer DV-Anlagen auf einem Anwendungsgebiet forcieren woIIten. Allgemeine Entwicklungen (beispielsweise ein anwendungsunabhängiger Programmgenerator-Kern) sind offensichtlich entweder vernachlässigt oder nicht veröffentlicht worden.

Die Erfahrungen mit Programmgeneratoren - auch für spezielle DV-Systeme - sind sehr erfolgreich gewesen. Wünschenswert ist allerdings, daß solche Werkzeuge auch im Dialog (Einsatz vor Bildschirmen) benutz werden können.

Günter Mußtopf ist Mitarbeiter der SCS GmbH, Hamburg