Warum Assembler benutzen?

Assembler als Programmiersprache ist nicht mehr sehr populär heutzutage. Normalerweise wird eine dritte oder vierte Generationssprache benutzt.

Normalerweise - für "08/15" Anwendungen - ist dies genau richtig. Es gibt aber Situtationen in denen es nötig ist die Argumente für und gegen Assembler genau zu betrachten.

Auf der einen Seite sind die Argumente gegen die Benutzung von Assembler zum grossen Teil Vorurteile, auf der anderen Seite sind die Argumente für die Benutzung relativ unbekannt. Wenn man die Vorurteile gegen Assembler kennt und die Vorteile nicht kennt, wird es sehr schwer eine objektive Entscheidung bei der Wahl der Programmiersprache zu treffen.

Eine Regel bleibt wichtig - wie für jede Programmiersprache: ohne gut ausgebildete Leute kommt man nirgendwo hin, ohne gute Dokumentation enden Sie gar an einer unbekannten Position.

Unten finden Sie eine Übersicht über die wichtigsten Vorteile von assembler. Dannach werden wir versuchen die Vorurteile zu beseitigen. Wir beenden mit einer kurzen Zusammenfassung.

Die Vorteile von Assembler.

Das Arbeiten mit Assembler bietet eine Reihe von Möglichkeiten, welche nicht (in dieser Gesamtheit) verfügbar sind für 3GL- oder 4GL-Programmierer.

Abwehrfehler.
Wie oft passiert es das Ihre Anwendungen über etwas so simples wie einen S0C7 stolpern, oder über eine zu kleine Zwischendatei. Mit der Hilfe einer relativ einfachen Assemblerroutine können diese Probleme gehandhabt und gelöst werden. Ihre Anwendungen stürzen nicht einfach ab, sondern laufen weiter. Alle aufgetretenen Probleme werden protokolliert, und erlauben es dem Kontroller die nötigen Aktionen durchzuführen.
Benutzung von Speicher über der 16MB-Linie.
Es gibt immer noch viele Unternehmen die (gezwungenermassen) mit AMODE=24 umwandeln. Durch Ergänzung um kleine Assemblermodule können Ihre Anwendungsprogramme über der 16MB-Linie laufen und so den Druck unter der 16MB-Linie reduzieren.
Dynamische Speicherverwaltung.
Programme die Daten in Tabellen, Listen oder Bäumen pflegen, wissen oft nicht im Voraus wie groß der Speicherbedarf sein wird. In Assembler kann Speicher dynamisch zugeordnet und freigegeben werden. Dies erlaubt es nur den wirklich benötigten Speicher anzufordern und zu nutzen.
Optimierung.
State-of-the-art Compiler generieren sicher effizienten Kode. Sie können aber nicht entscheiden, welches Ihre speziellen Optimierungsziele sind. Da ein Programmierer die Struktur Ihrer Anwendung kennt, kann er diese Entscheidung treffen. Er kann zum Beispiel das Risiko einer page-steal Operation verringern, um so das Programm schneller zu machen und die Last auf dem paging Subsystem zu reduzieren.
Benutzung von Betriebssystemmöglichkeiten.
Viele dieser Möglichkeiten sind nicht nutzbar von höheren Programmiersprachen. Wenn sie nutzbar sind, ist z.T. der zusätzliche Aufwand erheblich, sodaß ein möglicher Performancegewinn von diesem Aufwand überlagert wird.
Unter anderem sind zu nennen:
- Data spaces.
  Programme die große Mengen Speicher benötigen, können Data Spaces benutzen. Dies veringert den Zwang Arbeitsdateien anzulegen (welches wiederum I/Os spart) und zur selben Zeit wird der Bedarf an Speicher reduziert (welches out-of-storage abends vermeidet).
- Virtual look-aside facility.
  VLF ermöglicht es benannte Daten in Speicher ausserhalb des eigenen Addreßraumes zu halten. Für intensiv benutzte Daten (z.B. Member in bestimmten PDS-Dateien) kann dies die Zeit für I/Os für Ihre Anwendungen erheblich verkürzen.
- Gleichzeitiger Zugriff auf verschiedene Dateien.
  Wenn eine Anwendung Sätze aus zwei oder mehr Dateien lesen und/oder schreiben will, kann dies zur selben Zeit passieren. Dies ist sogar für Sätze der gleichen Datei möglich. Diese Überlappung kann erhebliche I/O-Wait Zeiten einsparen, besonders wenn die Sätze auf unterschiedlichen Volumes liegen.
- Subtasks.
  Durch Aufteilung auf mehrere Subtasks kann eine Task erheblich beschleunigt werden. Z.B. durch Verlagerung der nötigen Anlegung von Journalsätzen in eine zweite Task kann die Verkaufstransaktion beschleunigt werden.
- Reenterability.
  Indem häufig benutzte Programme reentrant gemacht werden, können diese in gemeinsam genutzten Speicher (bevorzugt über der 16MB Linie) gelegt werden. Dies bedeutet, das alle Programme, die diesen Kode benutzen, beschleunigt werden, weil die Wahrscheinlichkeit für einen Page Fault minimal wird.

Die Vorurteile gegen Assembler.

Es gibt verschiedene Vorurteile gegen das Arbeiten mit Assembler. Die Wichtigsten sind:

In Assembler ist strukturierte Programmierung unmöglich.
Dies ist nicht wahr. In diesem Bereich bietet Assembler tatsächlich mehr Möglichkeiten als viele 3GLs.
Pflege von Assemblerprogrammen ist viel teurer als die Pflege von 3GLs.
Als 3GLs eingeführt wurden mag dies gestimmt haben. Aber heute ist diese Aussage durchaus debatierbar.
Assembler ist eine umständliche Sprache, und schwer zu lernen.
Assembler ist in der Tat ein bischen weniger lesbar für den Laien als z.B. COBOL. Sprachen wie C und C++ auf der anderen Seite sind viel schwerer zu beherschen.

Zu 1.

In Assembler ist strukturierte Programmierung unmöglich.
Struktur in Programme zu bringen ist zu Allererst eine Frage des Stils und der Arbeitsmethode. Wenn die benutzte Programmiersprache gute Möglichkeiten in diesem Bereich bietet, kann das eine Hilfe sein, aber nicht mehr.

Im Bereich Segmentierung bietet Assembler mehr Möglichkeiten als 3GLs: Neben dem üblichen Unterprogrammen und Funktionen, kann man Programme in CSECTs unterteilen, welche wiederum in Unterprogramme und Funktionen aufgeteilt sein können.
Als Zusatz kann man zwischen verschiedenen Arten des Aufrufs wählen. Unter anderem: Standard 360-Linkage Konventionen, dem Linkage-Stack oder andere Aufrufmethoden, mit oder ohne Verzweigetabelle.
Für die Weitergabe von Parametern schließlich besteht die Wahl zwischen Weitergabe des Wertes, der Referenz oder eine Mischung hiervon.
Bei der Schleifenkontrolle gibt es in Assembler mit 3GLs vergleichbaren Möglichkeiten. Dies sind die so genannten "branch on index" und "branch on count" Instruktionen mit ihren relativen Brüdern. Mit Hilfe von Macros kann man diese Intruktionen um weitere mächtige Möglichkeiten erweitern.
Genau wie viele 3GLs hat Assembler ein Copyfeature um Standardkode von einem Bibliotheksmember in das Programm zu kopieren.
Die Macro-Möglichkeit schließlich bietet ein breites Spektrum um Struktur in Programme zu bringen und wiederkehrende Programmkonstrukte zu standardisieren. Bei Benutzung von conditional assembly ist es immer möglich den generierten Kode zu optimieren. Die meisten 3GLs bieten keine vergleichbare Funktion.

Zu 2.

Die Pflege von Assembler Programmen ist weit teurer als die Pflege von 3GLs.
Als 3GLs zuerst eingeführt wurden, gab es eine breite Basis existierender Assembler Programme. Weil strukturierte Programmierung relativ neu in jenen Tagen war, liesen diese Programme vieles zu wünschen übrig, wenn es um Struktur ging. In Assembler - wie in jeder anderen Sprache auch - kann man beliebig viel oder wenig Struktur erzeugen. Mit allen Konsequenzen für die spätere Pflegbarkeit.
In Assembler gibt es mehr Möglichkeiten, als in vielen 3GLs ein Chaos anzurichten. Dank der Macro-Möglichkeit gibt es aber mehrere wichtige Optionen mehr Struktur zu erzeugen als in anderen Sprachen.

Eine sehr wichtige Frage ist die Frage des Stils. Ein 3GL-Programmierer der nebenher "ein bischen Assembler" macht, kann sich niemals mit einem professionellem Assembler-Programmierer messen. Die Resultate sind meßbar und zwar nicht nur in der Zeit in der eine gegebene Arbeit erledigt wird, sondern auch in der Qualität des produzierten Kodes. Das Hauptproblem ist demnach: wie finde ich den erfahrenen Profi. Ein Problem das Sie aber immer haben, egal welche Sprache Sie wählen.

Um also einen fairen Vergleich für benötigte Mannpower zwischen Assembler und 3GLs durzuführen, muß man Handwerker mit Handwerker vergleichen und man muß das Alter der Programme (lies: Grad der Strukturierung) berücksichtigen und die Qualität der vorhandenen Dokumentation.

Unsere Erfahrung mit neuen Programmen ist ein ca. 10 bis 20-prozentiger Mehrbedarf für Entwicklung in Assembler. Wenn es um Pflege geht, ist der Unterschied zu abhängig von der Verfügbarkeit von Dokumentation und der Struktur der Programme um sinnvolle Zahlen zu liefern.

Ein Beispiel: Einer unserer Kunden besitzt ein Assembler Modul (von uns) und ein COBOL-Modul. Beide tun exakt dasselbe. Die letzten paar Änderungen wurden von einem Assembler-Programmierer an einem Tag durchgeführt, wohingegen der Cobol-Programmierer 3 Tage brauchte. Obwohl dies außergewöhnlich klingt, zeigt es doch das Pflege eines Assembler Programmes nicht automatisch aufwendiger ist als Pflege eines 3GL Programmes.

Zu 3.

Assembler ist eine umständliche Sprache, und schwer zu lernen.
Wenn Sie von "Laien" abhängig sind, sollten Sie sicher nicht Assembler wählen. Wie mit jeder anderen Sprache werden Sie nur Ihre eigenen Probleme erzeugen.
Natürlich gibt es auch Profies. Diese können nicht nur Assembler programmieren, sondern beherrschen auch die verschiedenen Optionen, die Assembler bietet. Dies ermöglicht eine zügige, effiziente und saubere Arbeit.

Zusammenfassung.

Die Argumente für und gegen den Gebrauch von Assembler können wie folgt zusammen gefaßt werden:

Arbeiten mit Assembler braucht ein kleines bischen mehr Zeit. Aber bei Weitem nicht soviel, wie man gemeinhin denkt.
Assembler bietet mehr Möglichkeiten zur Strukturierung, obwohl fehlender Professionalismus produziert leichter Pflegeprobleme.
In Assembler gibt es mehr Möglichkeiten Durchsatzprobleme zu lösen oder zu verhindern.
Man benötigt mehr Zeit einen Profi zu finden.

Zusammenfassend unser Tipp: Kein Assembler wenn es nicht sein muß. Auf der anderen Seite, wenn es Gründe gibt, nur nicht genieren; Assembler ist nicht furchteinflössend. Und wenn Sie Assembler einsetzen, bitte nur für die Module die davon profitieren. Der größere Teil Ihrer Anwendung wird wahrscheinlich am besten in Ihrer Lieblings-3GL oder 4GL geschrieben.

Schließlich, für manche Anwendungen gibt es keine Alternative zu Assembler. Dies gilt insbesondere für viele Exits.
Nicht nur das Betriebssystem, sondern auch viele Standard Produkte sind mit Exitpunkten ausgestattet, damit Installationen diese Software an ihre Bedürfnisse anpassen können. Für viele Exits ist Assembler die einzige Sprache. Mit obigen Argumenten sollte dies (ab jetzt hoffentlich) kein unüberwindbares Problem sein.

Diese Seite ist Mitglied im einem Web-Ring. Sie sind eingeladen die Liste der Mainframe-Liebhaber-Internetseiten zu durchstöbern.		Dinos sind nicht tod. Sie sind am Leben und fühlen sich wohl in einem Rechenzentrum in Ihrer Nähe. Sie sprechen seltsame Sprachen und betreiben Zauberei mit dem Computer. Und falls Sie auf ihr endgültiges Aussterben warten: Dinosaurier waren die Herren der Welt für 155 Millionen Jahren!
Dinos und andere Anachronismen. [ Join Now \| Ring Hub \| Random \| << Prev \| Next >> ]

Nach die Vorteile von Assembler.
Nach die Vorurteile gegen Assembler.
Nach die Zusammenfassung.

Nach die deutsche Homepage.
Nach die allgemeine Homepage.

Hier finden Sie die Logos unserer Sponsoren und die Logos der Web-Standarts an die sich diese Seite hält.