Der neue, kleine OMIKRON.-Assembler
Neu, weil er wenig mit dem alten Ideal-Assembler von OMIKRON gemein hat. Klein, weil demnächst eine Makroversion erscheinen wird. Die Makroversion wird im Gegensatz zu der vorliegenden neben Makros auch mit Objektmodulen arbeiten können und dazu natürlich auch einen Linker beinhalten. Der Assembler wird aller Voraussicht nach Objektcode im DRI- und auch im GST-Format erzeugen können. Diese Objektdateien kann dann selbstverständlich auch der Linker verarbeiten. Soviel zu dem, was der Kleine nicht kann, viel interessanter dürften aber seine Fähigkeiten sein.
Die Benutzeroberfläche kam mir auf dem ersten Blick sehr bekannt vor. In den oberen zwei Zeilen werden dabei die über die Funktionstasten oder Maus erreichbaren Funktionen dargestellt, der integrierte Editor setzt, genau wie das BASIC der gleichen Firma, die Eingaben sofort in tokenisierte Form um. Diese Vorübersetzung hat zur Folge, daß der reine Assemblerlauf auf Übersetzungsraten von durchschnittlich 1.1 Millionen Zeilen pro Minute kommt. Wenn man der Angabe, die nach jeder Übersetzung ausgegeben wird glauben dart und ich habe keinen Grund dies nicht zu tun wird diese Zahl im Normalfall noch um einiges übertroffen. Geht man aber von normal großen Sourcecode aus (bis 1000 Zeilen), würden 10% der Geschwindigkeit auch ausreichen. Der eigentliche Vorteil der Tokenisierung liegt neben dem geringeren Speicherbedarf auf Platte in der sofortigen Syntaxüberprüfung. Einige Fehler wie doppelte Vergabe eines Labelnamens werden so direkt bei der Eingabe abgefangen. Solange die als fehlerhaft erkannte Zeile nicht korrigiert ist, weigert sich der Editor, diese zu verlassen bzw. denn weitere Zeilen anzunehmen. Die ausgegebene Meldung beschreibt den Fehler allerdings so genau, daß selbst Assemblereinsteiger, ohne lange in Büchern suchen zu müssen, die korrigierte Zeile dem Assembler schmackhaft machen können.
Automatische Formatierung
Der dritte Vorteil schließlich ist die ordentliche Formatierung des Quelltextes (ohne eigenes Zutun). Da die Zeile nach der Eingabe erst einmal übersetzt, die tokenisierte Zeile dann wieder in ASCII-Text umgewandelt wird, der Assembler also sofort zwischen Labelnamen. Befehl und Kommentar unterscheiden kann, werden diese Teile bei der Bildschirmausgabe auf zuvor einstellbare Tabulator Positionen gesetzt. Auch werden alle Befehle in Motorola-Standard umgesetzt, aus move D0,A0 wird also movea D0,A0.
Die Geschwindigkeit des Editors leidet unter dieser zusätzlichen Arbeit allerdings nicht. Die Arbeitsweise dürfte auch fast jedem ST-Anwender bekannt sein. Der neue ST-BASIC-Standard, OMIKRON.BASIC, arbeitet ja bekanntlich nach derselben Methode.
Da der Editor leider nicht in GEM oder wenigstens in eine nachempfundene GEM-Umgebung eingebunden ist, bleiben der Maus andere Aufgaben als die unter GEM üblichen wie Fenster verschieben oder in der Menüleiste herumfahren. Die auffälligste stellt dabei das Scrollen bei Erreichen des oberen beziehungsweise des unteren Bildschirmrandes dar (kann auch zu unschönen Erlebnissen führen, da der Rechner selbstverständlich nicht merkt, ob ein Scrollen auch beabsichtigt ist). Bei dauerhaftem Betätigen der linken Maustaste ist so das Markieren eines Blockes auch über die Bildschirmgrenzen hinaus möglich. Zumindest das ist eine Funktion, die ich jedem Editor “wünschen” würde.
Aber er bietet noch andere Besonderheiten, die in jedem Programmeditor möglich sein sollten. Für Assemblerprogrammierer, und hier besonders für den Einsteiger, stellen die oft benötigen Umrechnungen zwischen den verschiedenen Zahlensystemen ein Problem dar. Der OMIKRON.Assembler stellt dazu eine sehr gelungene und schnelleren Arbeitsdrang nicht bremsende Option zur Verfügung. Dazu wird der Cursor auf eine Zahl in beliebigen Format plaziert, durch Drücken einer bestimmten Tastenkombination wird diese Zahl der Reihe nach entweder in Hex-, Bin-, Dezimal- oder ASCII-Zeichen umgewandelt. Sollten diese einfache Umrechnungen nicht ausreichen, kann auch ein Rechner aufgerufen werden, der mit Zahlen in den oben genannten Zahlensystemen rechnen kann. Die so erzielten Ergebnisse können, sofern gewünscht, direkt in den Text übernommen werden.
Fehlerhandling
Im ganzen ist mit dem System sehr schön und vor allem sehr schnell zu arbeiten. Dazu gehört auch das schnelle Anspringen von fehlerhaften Zeilen, die erst beim Assemblieren entdeckt werden, und später. wenn der Text im ganzen übersetzt ist, das Austesten mit dem sehr leistungsfähigen Debugger.
Sollten beim Assemblieren Fehler gefunden werden (und das wird nicht ausbleiben), werden die fehlerhaften Zeilen intern mit Fehlermeldungen gespeichert. Nach dem Assemblerlauf kann dann auf Tastendruck von einer fehlerhaften Zeile direkt zur nächsten gesprungen werden. Dabei wird die jeweilige Fehlermeldung in der Statuszeile ausgegeben. Da es sich bei dieser Art von Fehlern zumeist um unbekannte Labels oder ähnliches handelt, die auf Schreibfehler zurückzuführen sind, dürfte die Erstellung eines lauffähigen Programmes nicht mehr allzu schwer fallen. Wenn einmal Texte, die mit anderen Assemblern erstellt wurden, also nicht nach den Spezifikationen von OMIKRON, tokenisiert sind oder sogar nicht die genauen Vorgaben des Motorola-Standards einhalten, vorkommen, sollten auch keine Probleme entstehen, da auch ASCII Dateien eingelesen werden können. Sollte im Quelltext allerdings die Unterstützung von mehreren Data- und Textsegmenten verlangt werden (kein Standard, aber in anderen Assemblern nicht unüblich), müssen die nicht tokenisierbaren Zeilen des Textes angepaßt werden. Dies gilt natürlich auch für Quelltexte von Assemblern, die sich eigene Pseudoopcodes geschaffen haben (Pseudoopcodes sind im Gegensatz zu Opcodes keine Befehle für den 68000-Prozessor, werden aber vom Assembler benötigt, um z.B. Speicher reservieren zu können. Dazu gibt es den Standardbefehl DS.). Von diesen selbstgeschaffenen Pseudoopcodes hat der OMIKRON.-Assembler allerdings auch einige zu bieten. Ich möchte auch nicht deren Nutzen für den Programmierer, der ständig mit seinem Assembler arbeitet, bestreiten, aber ich sehe schon die Programme für die Programmierpraxis, die von niemanden hier verstanden werden, weil massig unverständliche Opcodes Verwendung finden.
Assembler und BASIC
Jetzt stellt sich die Frage, für wen dieser Assembler am besten geeignet ist. Kleinere Programme, bei denen man schnell ein paar Hardwareregister beschreiben oder auf geschützte RAM Bereiche zugreifen will, können sehr schnell geschrieben und ausgetestet werden. Große Programme, die man nicht in kleine Module zerlegen will, profitieren natürlich auch von den schnellen Übersetzungszeiten. Nicht geeignet ist er für Leute, die gerne Makros verwenden oder ihre Assemblerwerke in Hochsprachen einbinden wollen. Mit einer Ausnahme. OMIKRON. BASIC-Programmierer werden voll unterstützt, denn nachdem ein Programm assembliert ist, bleibt es dem Programmierer überlassen es als ausführbares Programm, als Datazeilen oder als String für den INLINE-Befehl des BASIC 3.00 abzulegen. In dieser BASICversion soll auch die Einbindung von relozierbaren, also an beliebige RAM-Adressen zu ladende Programme möglich sein. Das ist allerdings ein BASICproblem und soll hier nicht weiter interessieren. Es ist nur fraglich, ob sich die von Haus aus schnellen OMIKRON.BASIC-Programme mit Assemblerroutinen noch ausschlaggebend beschleunigen lassen. Sollte einer der oben genannten Gründe auf Sie zutreffen, können Sie sich auch über den separaten Debugger freuen, der den Preis des Pakets eigentlich fast alleine rechtfertigen würde.
Zusammenarbeit mit dem Debugger
Interessant ist in erster Linie die Zusammenarbeit mit dem Assembler. Der Debugger kann von diesen auf zwei Arten aufgerufen werden. Zum einen über eine Funktionstaste, zum anderen bietet der Assembler nach erfolgreicher Assemblierung die Wahl zwischen Abspeichern und der Übergabe des Programmes an den Debugger, wobei auch die Labelnamen übergeben werden können. Und schon kann man z.B. in Einzelschritten die Tätigkeit seines Programmes verfolgen. Sollte dabei festgestellt werden, daß eine Zeile geändert werden muß, gelangt man durch die Tastenkombination Controls Help in den Assembler zurück, und zwar genau an die Zeile, die zuletzt im Debugger ausgeführt wurde. Dieses schnelle Korrigieren führt mitunter, zumindest bei mir, zu recht sorglosem Umgang z.B. mit Schleifenzählern. Als ich noch mit einen recht langsamen Assembler gearbeitet habe, habe ich mir lieber eine Minute lang überlegt, wie oft eine Schleife durchlaufen werden soll, als meinen Source einmal mehr durch diverse Batchdateien zu quälen und dann den Fehler nur recht umständlich einkreisen zu können. Mit dem OMIKRON. Assembler habe ich mir nun eine andere Arbeitsweise angewöhnt: F1 für Assemblerstart drücken, der ist fertig, bevor ich den Finger von der Taste habe, dann Return drücken, und der Debugger meldet sich. Jetzt. z.B. um schnell an die gewünschte Stelle zu gelangen, “g.schleife" (steht für: Ausführen des Programmes bis zum Breakpoint Schleife), sie wird dann in Einzelschritten abgearbeitet. Ah., der Wert stimmt nicht..., Control+Help -jetzt befinde ich mich wieder im Assembler, und zwar genau in der Zeile, die ich ändern möchte. Der ganze Vorgang hat nicht einmal eine Minute gedauert. Wozu soll ich mir also bei dieser Geschwindigkeit den Kopf wegen Kleinigkeiten wie Schleifenzählern zerbrechen.
Der Bildschirmaufbau des Debuggers entspricht den des Assemblers. In den oberen Zeilen sind also die Funktionen, die über die Funktionstasten erreichbar sind, aufgeführt. Darunter sind alle Register mit ihren momentanen Werten zu sehen, die durch Mausklick auch jederzeit mit anderen Werten belegt werden können. Die Maus kann hier ebenfalls zum Scrollen benutzt werden, darüber hinaus lassen sich durch Anwählen mit der rechten Maustaste beliebige Worte und Werte an die Cursorposition kopieren. Dadurch kann das lästige Abtippen von Adressen oder Sonstigem, was z.B. zum Setzen von Breakpoints benötigt werden, entfallen. An Befehlsarmut krankt er auch nicht, so können über Funktionstasten schon vier verschiedene Arten des Tracens, also der Einzelschrittabarbeitung, gewählt werden. Soll das Tracen automatisiert werden, kann auch der UNTRACE-Befehl verwendet werden. Als Abbruch dienen hier Bedingungen, die sehr einfach mit IF-Anweisungen gesetzt werden. Eine Bedingung könnte z.B. “IF ^d0=100" lauten. Der UNTRACE-Befehl arbeitet dann entweder die angegebene Anzahl von Befehlen ab oder bricht den Testlauf ab, wenn das Register D0 den Wert 100 angenommen hat. Dabei werden die letzten 256 ausgeführten Befehle und die dazugehörigen Registerinhalte im sogenannten Cachespeicher abgelegt, den man sich bei Bedarf auch ausgeben lassen kann. Auf diese Art lassen sich wirklich sehr einfach Fehler im Programm finden. Selbstverständlich sind auch alle Befehle zur "Speicherbearbeitung” wie das Anzeigen mit anschließender Änderung von beliebigen Speicherbereichen oder das Suchen nach bestimmten Speicherinhalten implementiert. Dabei ist es völlig egal, ob der zu suchende Wert als Zahl, ASCII Text oder als 68000-Befehl angegeben wird.
Einer der wichtigsten Befehle ist der List-bzw. der Disassemble-Befehl. Der unterschied zwischen den beiden ist, daß bei Disassemble zu den Mnemonic auch der Speicherinhalt ausgegeben wird, beim LISTen, sollte eine Symboltabelle mit dem Programm geladen worden sein, auch die Labelnamen. Sollte allerdings keine Symboltabelle geladen sein, erzeugt der Debugger leider keine eigenen Labelnamen, es ist also kein Reassembler. Dafür können alle Ausgaben sehr einfach auf einen Drucker oder auf eine Datei umgeleitet werden.
Um den Debugger auch jederzeit zur Hand zu haben, wird er durch den Resident-Befehl im Speicher gehalten, wobei er dann alle “Bombentraps” abfängt und die Suche der fehlerhaften Programmstelle ermöglicht. Der Aufruf des residenten Debuggers ohne Bombenwurf ist selbstverständlich auch möglich und erfolgt durch Betätigen von Alternate+Help. also der Kombination, die normal die Hardcopy funkt ion aufruft. Sollte aber nicht der Debugger gemeint sein, kann zur Hardcopyroutine weitergesprungen werden.
Am Schuß möchte ich noch eine Besonderheit ansprechen, den Switch-Befehl. Daß damit zwischen Programmbild schirm und Bildschirm des Debuggers hin- und hergeschaltet werden kann, ist wohl nicht unbedingt etwas Besonderes. Sollte aber mit zwei Monitoren und einer Monitorumschaltbox mit Softwareumschaltung gearbeitet werden, schaltet der Debugger bei Erstellung von “farbigen" Programmen automatisch zwischen farbigem und monochromem Monitor um. Die Programmierer von OMIKRON, beweisen damit einmal mehr, mit welcher Liebe zum Detail sie arbeiten, und daß es auch an guten Ideen nicht fehlt.
Fazit
Der OMIKRON.-Assembler konnte, was die Bedienung und vor allem die Geschwindigkeit, mit der er assemblies, wodurch er eine sehr schnelle Programmentwicklung ermöglicht, einen sehr guten Eindruck hinterlassen. Daß die Erzeugung von Objektdateien und die Verwendung von Makrodefinitionen nicht möglich ist, mag den einen oder anderen ST-Anwender abschrecken, aber ich denke, es geht vielen wie mir, denn ich programmiere viel in Assembler, hatte aber noch nie das Verlangen, mit Makros zu arbeiten oder Assemblerroutinen in C einzubinden. Außerdem konnte nach kurzer Durchsicht der eingegangenen Karten unserer Leserumfrage festgestellt werden, daß schätzungsweise 70% unserer Leser in BASIC programmieren, die mit dem recht billigen OMIKRON.BASIC auch voll zufrieden sein werden. Sollte trotzdem jemand nicht auf diese Funktionen verzichten können und kurz vor dem Kauf eines Assemblers stehen, sollte auf das Erscheinen des großen, eben des Makroassemblers von OMIKRON, (noch im 1. Quartal ’89) gewartet werden, es wird sich bestimmt lohnen. Die Preise betragen DM 99,- für den “kleinen" und DM 198,- für den Makroassembler.
OMIKRON.Software Erlachstr. 15a 7534 Rirkenfeld 2