Das endliche Assemblerbuch

In dem Buch versuche ich natürlich in erste Linie Assembler vorzustellen. Da aber auch Hardwarewissen und Hintergrundwissen unabdingbar ist, wird auch auf diese „Randbereiche“ eingegangen. Wer Assembler programmiert, sollte zudem auch ein allgemeines Computerwissen haben. Ich vergleiche und beschreibe daher auch den Amiga von anderer Seite, und setze in der Konkurrenz aus, die ja bekanntlich nicht schläft. So werden die Leser etwas über Atari und dessen Ansatz- Multitasking, Macintosh, und dessen Oberflächendesign, PC und dessen Windows-Aufsatz erfahren. Dieses Wissen ist essenziell, und wesentlich für den Verstand und Einsatz von Computern. Der Amiga wird dann in einem ganz neuen Licht erscheinen, und nicht nur unter der Rubrik „Spielecomputer“ seinen Platz haben.

Mehr als 20 Jahre schlummerte auf dem Datenträger dieses unvollendete Amiga-Buch. Als ich 18-19 Jahre alt war, begann ich mit dem Schreiben und habe dann etwa 2 Jahre daran gearbeitet. Über 400 Seiten sind in der Zeit entstanden. Geschrieben habe ich es auf dem Amiga in einem einfachen Text-Editor, später habe ich große Teile in LaTeX konvertiert. Als das Studium kam, und Verlage an einem Buch nicht mehr interessiert waren (die große Amiga-Zeit war vorbei), wanderte der Buchentwurf auf die Platte. Ihn für immer dort zu belassen war zu schade, und so habe ich den LaTeX-Text in AsciiDoc (http://www.methods.co.nz/asciidoc/) konvertiert und unter http://retrobude.de/dokumente/amiga-assembler-buch/ frei unter der Creative Commons (CC-by-nc-nd) online gesetzt.

Ganz klar ist das Buch auf dem Stand von 1993 und alles, was nach 1993 geschah, thematisiert das Buch nicht; weder der Untergang von Commodore/Amiga, noch die Weiterentwicklung des Betriebssystems. Damit das Buch von größerem Nutzen ist, müsste noch (etwas) Arbeit hineingesteckt werden:

Das sind die Dinge, die gemacht werden müssen, als Zweites kann man an Erweiterungen denken:

Wer hat Lust zu helfen? Unter http://retrobude.de/dokumente/amiga-assembler-buch/ ist der aktuelle Stand für jeden einsehbar. Interessenten würde ich dann Kapitel für Kapitel iterativ und inkrementell zukommen lassen (jeder sagt, was er gerne machen möchte, also Korrekturlesen, ins Format bringen, erweitern, …), das dann mergen und weitergeben und so könnte am Ende ein umfangreiches und aktuelles Assembler-Buch für den Amiga stehen.

Ich danke Wolfgang Hosemann und Ao Toprak für die Durchsicht einiger Kapitel.

In den Assembler-Listings schreibe ich die Mnemonics (add, move, …​) und Register klein, im Text konsequent groß (ADD, D7, …​).

Wenn man mit dem Computer arbeitet, wird man zwangsläufig mit zwei wichtigen Stellenwertsystemen konfrontiert. (Duden Informatik sagt zu Stellenwertsystem: „System zur Darstellung von Zahlen durch Ziffern, bei denen der Wert einer Ziffer von der Stelle abhängt, an welcher sie innerhalb einer Zahl geschrieben ist“.)

Diese beiden Systeme sind das Hexadezimalsystem (oder Sedezimalsystem) und das Dualsystem (oder Binärsystem). Unser allgegenwärtiges Stellenwertsystem, das Dezimalsystem oder Zehnersystem, bietet die Ziffern 0-9 zur Darstellung von Zahlen. Man sagt, wir haben die Basis von 10, da für jede Zahl von 0 bis 9 eine verschiedene Ziffer existiert. Wir sind es gewöhnt, mit dem Zehnersystem umzugehen, ist uns meist die Arbeitsweise, wie wir z. B. addieren oder multiplizieren, unbewusst. (Warum gerade 10 die Basis für zehn verschiedene Zahlen ist, und wir mit Dezimalzahlen arbeiten, ist wohl durch die 10 Finger erklärt, die ein Mensch normalerweise hat. Es vereinfacht auch das Fingerrechnen. Hintergründe zu dieser Theorie erfahren Leser in den Büchern „Ein Himmel voller Zahlen: Auf den Spuren mathematischer Wahrheit“ von John D. Barrow, „Number Words and Number Symbols: Cultural History of Numbers“ von Karl Menninger.)

Da die dezimale Zahl aus Zehnerpotenzen zusammengesetzt ist, müssen wir sie nun als Summe von Zweierpotenzen darstellen. Wir wollen dies am Beispiel der Zahl 100 nachvollziehen.

Im praktischen Leben sieht das dann so aus: Aus der zuletzt aufgelisteten Tabelle suche ich die höchstmögliche Zahl der Reihe nach aus, die in die gesuchte hineinpasst. Das setze ich bis zum Ende fort. Das Ergebnis, ob eine Zahl hineinpasst oder nicht, quittiere ich mit einer Eins oder Null. Wählen wir die Zahl 1000.

Die Binärzahl zum Äquivalent 1000 ist %01111101000.

Der Mikroprozessor ist eine integrierte Schaltung (IS), oder auch Integrated Circuit (IC) genannt. Die integrierten Schaltungen erlauben es, mehrere tausend Bauteile, wie Transistoren, Kondensatoren, Widerstände und Spulen auf kleinsten Raum unterzubringen. Die erste Integrierte Schaltung, die 1958 von Jack Kilby gebaut wurde, konnte 4 Transistoren beherbergen. Durch die vielen Jahre hindurch ist die Chip-Technologie heute so weit, dass 1,2 Millionen (1200000) Transistoren (so viel hat der MC68040) auf einem Fingernagel untergebracht werden können.

Ein Mikroprozessor ist etwas Besonderes, denn er ist ein IC, der programmierbar ist und Befehlsfolgen abarbeiten kann. So sind Mikroprozessoren nicht nur auf den Bereich der Computer beschränkt, sondern auch in Taschenrechnern, Radios, Autos, Fernsehern, Videorekordern und Spielautomaten zu finden.

Die Präsentation der ersten Prozessoren gelang 1970 den Herstellern Intel (Internationale Elektronik oder auch Intelligente Elektronik) und Texas Instruments. Die damaligen Prozessoren gehörten der ersten Mikroprozessorgeneration an.

Motorola begab sich mit dem 6800 (der Vorgänger vom MC68000) in die zweite Generation. Die dritte Generation ist etwa 1976 anzusetzen. Sie brachte Prozessoren wie den 6502 (ist im VC 20, Vorgänger vom C-64, eingesetzt), der von der Firma MOS Technology stammt (eine Firma, die sich Commodore später unter den Nagel gerissen hat) und den Z80 von Zilog (eine von Intel abgespaltene Gruppe) hervor. Im Jahre 1982 waren der 6502 und der Z80 die am weitesten verbreiteten Mikroprozessoren.

Nun sind wir mit dem MC68000 in der vierten Generation. Dieses Buch beschäftigt sich mit der Programmierung des MC68000 auf dem Amiga Computer.

Assembler ist die Grundsprache jedes Computers. Doch war da nicht noch was von Maschinensprache? Sollte nicht sie die Grundsprache sein? Gibt es denn da einen Unterschied oder ist es vielleicht dasselbe mit einer anderen Bezeichnung? Genaugenommen gibt es da einen kleinen Unterschied, denn wenn wir von Assembler reden, meinen wir meist schon eine kleine Programmiersprache. Während in der Maschinensprache nur mit Binärzahlen programmiert wird, so bringt uns Assembler mit seinen Befehlen einen großen Schritt voran. Diese Befehle werden Mnemonics genannt, was im Englischen für „Gedächtnisstütze“ steht und seinen Ursprung im griechischen Wort mnēmoniká „Gedächtnis“ hat. Man muss sich nicht mehr mit elendig langen Zahlenkolonnen herumärgern, sondern kann jeder dieser Zahlenreihe auch Namen geben und ich finde, dass RTI leichter zu merken ist als $4ef9.

Assembler ist bei jedem Computer anders. Wer also schon mit dem C-64, den kleinen Ataris, den Schneider CPC, oder dem Sinclair Spectrum (Taschenrechner mit Tastatur) in Assembler programmiert hat, und nun diese Kenntnisse auf dem Amiga übernehmen will, der ist aufgeschmissen. Das heißt natürlich nicht, das gesamte Wissen wird unwichtig: wer die Denkweise einmal beherrscht, kann leichter auf andere Prozessoren umsatteln.

Übrigens, noch zum Thema C-64 Prozessor: Der Hauptprozessor, der im C-64 das Rennen macht, ist aber auch im Amiga eingebaut, jedoch da hat er auf der Platine die ehrenwerte Aufgabe als Tastaturprozessor. (Ganz schön heruntergekommen, wenn man bedenkt, zu welchem Ruhm er dem C-64 verholfen hatte!)

Eines der wichtigsten Fakten, die der MC68000 aufzuweisen hat, ist die Anzahl und Breite von Daten- und Adressregistern. Das bringt uns zum Begriff Register und das Wort wird noch häufiger fallen. Ein Register ist ein kleiner Speicherplatz auf dem Prozessor. Auf diesen Speicherplatz ist schnell zuzugreifen, da die Daten „nicht so weit entfernt sind“.

Da es praktisch und schneller ist, mit Registern als mit Speicher zu arbeiten, haben die Entwickler nach dem Motto „Darf es auch etwas mehr sein?“ beschlossen, mit Registern nicht zu geizen. Eine heraus stechende Eigenschaft ist nun die Anzahl der Register. Insgesamt sind es 16(!) an der Zahl.

Der 68000 hat acht Daten- und acht Adressregister mit der Breite von je 32 Bit. Dies soll in der Skizze verdeutlicht werden.

und

In jedes dieser Register lässt sich ein Wert hineinschreiben. Natürlich kann der Inhalt des Registers wieder in an anderes Ziel übertragen werden. Auch kann der Programmierer diese Register untereinander verknüpfen, um Rechenoperationen möglich zu machen.

Die wichtigste Aufgabe eines Prozessors ist seine Fähigkeit, Daten zu verarbeiten, und dies geschieht mithilfe von Registern. Das Wort Register wird uns daher im ganzen Buch begegnen.

Die Datenregister werden mit einem D und die Adressregister mit einem führenden A bezeichnet. Da wir 8 von jeder Sorte haben, und der Computer bei Null zu zählen beginnt, bezeichnet man die Datenregister mit D0, D1, D2, …​, D7 und ebenso die Adressregister von A0, A1, A2 …​ , A7. Diese große Anzahl von Registern, die schnell verarbeitet werden können, muss man natürlich nutzen. So sind Compiler darauf spezialisiert mehr oder weniger diese 15 Register zu nutzen (das A7-Register ist schon für andere Zwecke besetzt, für den sogenannten Stack-Pointer). Falls Compiler dies nicht tun und nur einen schlechten Programmcode erzeugen, weil sie z. B. verschwenderisch mit Registern um sich werfen, gibt es noch Optimierer. (Wenn etwa ein Register ein Wert enthält, und dieser wird noch einmal in dieses Register geschrieben – zwei gleiche Zeilen --, kann eine Zeile verschwinden.) Ein Optimierer kann ein Assemblerprogramm scannen, und durch geschickte Algorithmen alle Register weitestgehend ausreizen. Je besser die Registerwahl ist, desto schneller läuft ein Programm ab, da lästiges Zwischenspeichern in den Hauptspeicher erspart bleibt. Speicherzugriffe sind immer langsam, das sollte bei der Programmoptimierung immer beachtet werden.

Prozessoren wie der Intel oder C-64 Chip haben den Vorteil der vielen Register nicht, die zudem alle gleichberechtigt verknüpft werden können. Bei den alten Prozessoren gibt es eine Rangordnung. So gibt es z. B. ein Register, den Akkumulator (AX-Register beim Intel), über den nur alle Rechnungen laufen können, oder ein Register, das nur zum Zählen (CX-Regsiter beim Intel) gedacht ist. (An unsere PC-Übersteiger: Ich möchte gar nicht erst wissen, was für ein Aufwand es sein muss, schon 2 Schleifen zu schachteln.)

Doch, um einen Computer mithilfe eines Prozessors zum Laufen zu bringen, benötigt man noch eine Zelle, in welchem der aktuelle Programmstand drinsteht. Es ist der schon erwähnte Program Counter, kurz PC (So hat eigentlich jeder, der einen Computer besitzt einen PC). Er wird bei der Programmausführung immer wieder der aktuellen Adresse angepasst.

Um den Prozessor zu programmieren, d. h. dessen Register und Speicher zu verändern, benötigen wir die schon erwähnten Befehle bzw. Mnemonics. Der 68000 kennt 56 Grundbefehle. Diese unterscheiden sich durch ihre verschiedenen Aufgaben.

Der MC68020 erweitert diese Spezialbefehle insofern, als Coprozessorsteuerungsbefehle hinzukommen, so z. B. Befehle, die den Matheprozessor ansprechen.

Natürlich kann der Amiga nicht unendliche große Zahlen verarbeiten. Ihm sind durch die Registerlänge von 32 Bit Grenzen gesetzt. Doch sollten wir nicht betrübt sein, der C-64 hat nur einen Zahlenbereich, der durch 8 Bit gegeben ist, also Zahlen bis 256. 32 Bit Zahlen dagegen können den Zahlenbereich von Null bis 2³² = $ffffffff = 4,9*10⁹ darstellen. Für viele Anwendungen mit Ganzzahlen ist das ausreichend.

Weil man nicht immer von 32 Bit Zahlen reden möchte, gab man ihnen einen anderen Namen: Long oder Longword. Der Name wird gleich noch etwas deutlicher.

Eine weitere Unterteilung umfasst 16 Bit, auch Word genannt. Daher auch der Name Long-Word, weil sie doppelt so groß sind. Wir sollten uns merken, wenn wir rechnen oder Werte benötigen, falls es geht, auf Longs zu verzichten. Das wird in den meisten Fällen gelingen, denn die 32 Bit Werte werden nur bei Adressen voll benötigt (und Adressen kann man ohnehin nicht multiplizieren), und Words reichen zum Arbeiten voll aus. Der Bereich der Words umfasst 16 Bit. Es können also Zahlen bis 2¹⁶ = %1111111111111111 = 65536 = $ffff gebildet werden. Doch oft ist auch dieser Bereich zu groß und er kostet immerhin noch 16 Bit. Somit kommen wir nun zur ursprünglichsten Speichereinheit: Dem Byte.

Die Überschrift ist vielleicht etwas irreführend, denn man versteht unter Assembler noch mehr, als nur die Programmiersprache. Ein Assembler ist auch ein Programm, das den Assembler Quelltext, den wir geschrieben haben und der in Textform vorliegt, in ein ausführbares Maschinenspracheprogramm umwandelt. Wie ein Assembler arbeitet, welche Befehle er versteht und übersetzt, wird in den letzten Kapiteln weiter vertieft.

Der Assembler, den die meisten nutzen, ist der Devpac Assembler von Hisoft (Kostenpunkt für 2.1 Version 140 DM), denn Seka’s Assembler-Zeiten sind out. (Ich glaube jetzt schon PD.) Devpac hat einen komfortablen Full-Screen Editor, eigentlich alles, was man so zum Programmieren braucht. Doch kommen auch neue Assembler wie der Maxon-Assembler von MAXON (149,-DM), der Code-X Assembler, ASM-One und der O.M.A. 2.0 Makro-Assembler (180 DM), der auch 68030 und 68882 Programmierung unterstützt, auf den Markt. Da diese aber bisher nicht so sehr verbreitet sind und recht neu sind, beschränke ich mich auf den Devpac Assembler. Um aktuell zu sein, will ich nicht verschweigen, dass auch Hisoft eine völlig neue Version herausbrachte, Devpac III. Wie seine Konkurrenten bietet er OS 2.0 Programmieren neue Include-Dateien (Dateien enthalten Informationen über das OS, wie Konstanten, Felder und Strukturen). Auch die Geschwindigkeit wurde verbessert, denn Devpac war nicht gerade der Schnellste.

Wir werden also Devpac hier als Assembler einsetzen. Wer jedoch einen anderen Assembler gekauft hat, nicht schlimm. Die meisten der anderen Assembler verfügen über denselben Befehlssatz, sodass von dieser Seite her keine Schwierigkeiten zu erwarten sind. Lediglich im Umgang sind sie geringfügig anders. Hier ist etwas Mut zum Ausprobieren gefragt, dann jedoch kommt man schnell dahinter, was in welcher Form verändert werden muss.

Dieses erste Unterkapitel soll uns helfen, den Devpac Assembler anzuwenden und dessen Arbeitsweise zu verstehen.

Bei dem Addierbefehl benötigen wir eine Quelle, von der die Werte kommen, und ein Ziel, worin die Ergebnisse der Addition abgelegt werden. Es wird also immer die Quelle mit dem Ziel addiert und das Ergebnis steht im Ziel.

Allgemein kann man wie bei dem MOVE-Befehl schreiben:

Wir haben schon 3 Quellen kennengelernt. Den Absolutwert, das Register und den Speicher. Ebenso zwei mögliche Ziele, das Register und der Speicher. Schreiben wir unser erstes Additionsprogramm, das den Umgang mit Ziel und Quelle ein wenig vertieft.

Programm:

Zweite Möglichkeit:

Dritte Möglichkeit:

Vierte Möglichkeit:

Fünfte Möglichkeit:

Sechste Möglichkeit:

Siebte Möglichkeit:

Achte Möglichkeit:

Bis zu der sechsten Möglichkeit wurden bewusst Register zur Verknüpfung gewählt.

Wer sich im Rechnen üben will, der kann ja einmal die Länge des Programms errechnen. Es sind vorweggenommen 108 Bytes.

Doch kann es oft sinnvoll sein, auch Variablenwerte heraufzusetzen. Ein Auszug könnte so aussehen:

oder

Ebenso wie der ADD-Befehl arbeitet der SUB-Befehl. Er subtrahiert das Ziel von der Quelle. Der Vorteil kann darin liegen, dass Register leicht auf Null gesetzt werden können. Denn anstatt des schon bekannten

lässt sich viel besser

schreiben. Dieser Trick mit den Adressregistern auf Null setzen ist merkenswert, denn auf Adressregister ist er schneller und kürzer.

Es kann schon einmal vorkommen, dass von der Zahl Null eine weitere Zahl abgezogen werden muss. Um nicht umständlicher weise z. B. die Zahl 13 von 0 abzuziehen,

bietet der 68000 einen weiteren Befehl an. Es ist der NEG Befehl, der, wie der Name schon sagt, das Argument, negiert. Das obige Beispiel würde mit dem NEG Befehl folgendermaßen viel einfacher zu gestalten sein.

Mit dem MUL-Befehl können 2 Werte multipliziert werden. Es ist jedoch darauf zu achten, dass bei der Anwendung des Befehls nur zwei 16 Bit Register verarbeitet werden können. Dies erscheint logisch, denn der Maximalwert ist ein 32-Bit Wert. Um jedoch zwei Long Zahlen zu multiplizieren benötigen wir 64 Bit, das bietet der einfache 68000 nicht. (Seine Nachfolger sind aber dazu dennoch in der Lage).

Beispiel:

Das D0-Register enthält das Ergebnis: dezimal 100, bzw. hexadezimal $64.

Der DIVU- oder DIVS-Befehl ist sehr komplex und nimmt auf der CPU relativ viel Platz ein. Ebenso wie beim MUL-Befehl gibt es hier eine Einschränkung. Der Wert, der unter dem Nenner steht (Divisor in mathematischen Kreisen genannt) muss eine 16-Bit Zahl sein, und der Divisor muss eine 32-Bit Zahl sein. Das Ergebnis ist wieder ein 16 Bit Wert. Ging die Division nicht auf, so steht im Hi-Word des Long-Ziels der Rest, und im Lo-Word der Ganzteil der Division (Quotient).

Lautet die Division 20/6, so würde im Lo-Word 3 stehen (die Sechs passt dreimal in die zwanzig) und der Rest von 2 würde im Hi-Byte stehen.

Beispiel:

Achtung! Ist der Divisor Null, so ist uns ein Guru mit der Meldung "0000 0005" gewiss, denn jeder weiß: Eine Division durch Null ist nicht erlaubt.

In den obigen Kapiteln beschrieb ich schon, was unter Taktzyklen zu verstehen ist. Ein Befehl, der von dem Prozessor verarbeitet wird, wird in seinen Phasen decodiert und ausgeführt. Die Ausführungszeiten sind verschieden lang und das ist einfach zu erklären, da ein Befehl, der z. B. ein Wert aus dem Speicher holt und ihn etwa mit einem anderen Wert aus dem Speicher verknüpft, länger zur Ausführung braucht als z. B. ein Befehl, der nur interne Register verknüpft. Daher sind die Ausführungszeiten bei Befehlen mit Registern noch erträglich. (Wiederum kann ich mich nur wiederholen und sagen: „Die Register ausreizen“.)

In den gleich folgenden Tabellen wird deutlich auffallen, dass Long-Words meistens eine höhere Ausführungszeit aufweisen als die Words. Über den Grund (16 Bit-Datenbus) haben wir schon gesprochen. Ich möchte die Zeiten in einer Tabelle anlegen, und daher ist es zwangsläufig, dass ich einige Abkürzungen einführe. Die Möglichkeiten einen Befehl anzusprechen, z. B. über Register oder Absolutwert, oder durch den Speicherinhalt fasst man unter den Begriff der Adressierungsart zusammen. Wenn ich also von der absoluten Adressierung spreche, so meine ich, dass die Quelle ein Absolutwert ist. Zur Abkürzung der Absoluten Adressierung wähle ich #xxx; ein Datenregister wird Dx genannt, falls das Datenregister eine Quelle ist; Dy, falls es Ziel sein soll; und Dn, wenn es allgemein in der Befehlscharakterisierung vorkommt. Das Gleiche gilt für Adressregister. Variablen werden mit xxxx abgekürzt. Die Abk. ea kennzeichnet die effektive Adresse, die dann in der Tabelle angegeben ist.

Beispiel:

Der Befehl Befehl.w Dx,Ay braucht also zur Ausführung 12 Taktzyklen.

Der Befehl Befehl.w #xxxx,Ay braucht 20 TZ, um ein Absolutwort mit einem Adressregister zu verbinden.

Da aus den schon beschriebenen Gründen Bytes nicht schneller als Words ausgeführt werden können, werden nur Word und Long Zeiten in der Tabelle aufgelistet. Da die Tabelle jedoch noch mehr aussagt, ob nämlich eine bestimmte Adressierungsart erlaubt ist oder nicht, werde ich, falls es notwendig ist, die Information, ob Byte Zugriff erlaubt ist, im Zweifelsfalle immer geben.

Wir wollen mit dem Datentransferbefehl MOVE beginnen.

Die gleichen Zeiten gelten für MOVE-Befehle, bei denen das Ziel ein Adressregister (d.h. move.w/l ea.Ay) ist.

Hier ist die AsciiDoc-Tabelle für den von Ihnen bereitgestellten Block:

Die Addierbefehle

Hier ist die AsciiDoc-Tabelle für den von Ihnen bereitgestellten Block:

die Endung A an ADD müsste eigentlich auch an das MOVE dran, da dadurch deutlich wird, dass eine Adresse das Ziel ist. Doch benötigt Devpac dies nicht zur Erkennung, da er selbst an der Endung erkennt, dass dies ein Adressregister ist. Das Gleiche gilt für Absolutzahlen, wo eigentlich ein I ans Ende gehört (z. B. SUBI).

Die Subtraktionsbefehle benötigen die gleiche Taktzyklenzeit wie die Additionsbefehle, daher sind sie hier nicht erneut aufgelistet.

Die Optimierung soll zeigen, wie man kürzere und schnellere Programme generiert. Mit dem Addiere-Befehl lässt sich auch schon optimiert und zeitsparend arbeiten. Man versucht in Assembler die langsamen Multiplikationen durch die fast 70-mal schnelleren Additionen zu ersetzen, denn die Multiplikationsbefehle und die noch längeren Divisionsbefehle haben Zeiten, wo man sich schon einen Kaffee holen kann. (Für die, die sich jetzt benachteiligt fühlen, natürlich auch Kakao, Milch, Tee und Limo!). Die Ersetzung gelingt in den meisten Fällen.

Wir wollen nun ein Beispiel kennenlernen, wo wir die Multiplikation mit konstanten Werten durch Additionen ersetzen können. Wenn man eine Zahl mit Zwei multiplizieren will, verdoppelt sich der Wert der Zahl. Aber anstatt diese mit Zwei zu multiplizieren, können wir auch den Wert der Variablen zu sich selbst addieren. Das Ergebnis wäre das gleiche.

Programm:

Im Debugger kann man das Ergebnis untersuchen, und es lautet 246. Doch steht dort wirklich 246? Warum steht denn da eine kleinere Zahl? Unbemerkt haben wir den Wert der Variablen Wert als dezimalen gewählt. Im Monitor allerdings erscheinen nur Hex-Werte. Doch der unterstützt uns auch hier mit den Zahlenformaten. Mit AmigaRechts+o erscheint ein kleines Fenster, indem die Formate umgerechnet werden können. Bei der Eingabe von einem Hexwert (Kennzeichnung ist ein Dollerzeichen $) oder einer Bin-Zahl (Kennzeichen das Prozentzeichen %) wird dies als Dezimalzahl und Hexzahl angezeigt. Dez-Werte oder Hex-Werte nach Bin zu wandeln geht leider nicht, und man vermisst diese Möglichkeit beim Speicherdurchschauen teilweise.

Unter diesen Befehlen, die schneller verarbeitet werden können, zählen die MOVEQ-Befehle (sprich „Move quick“), die Werte zwischen 0 und 127 (Vorzeichenbehaftet, daher nicht 255) in ein Datenregister schreiben können. Die Quelle darf jedoch nur ein Absolutwert sein, und das Ziel ein Datenregister. Das hört sich nach einer sehr starken Einengung an, ist es aber im Normalgebrauch nicht. Die Ausführungszeiten sprechen für die Einsetzung des Befehls und ich möchte in keinem Programm, welches Wertes zwischen 0 und 127 (oder negative Werte zwischen -1 und -127) in Datenregister schreibt (4 TZ), einen normalen MOVE-Befehl mehr entdecken (8, bzw. 12 TZ). Doch außer der schnelleren Ausführung ist der Quicky auch noch Platzsparender. Während bei der normalen Move-Anweisung 2 Bytes für die Kennung draufgehen, und dazu noch die 2 Bytes für benutzte Word, oder etwa 4 Bytes für Longs benötigt werden, so kommt der MOVEQ mit 2 Bytes aus. Das liegt daran, dass der Absolutwert vom MOVEQ immer in den 2 Bytes untergebracht ist. Das ist toll. Eine Ersparnis bei Longs von 4 Bytes!

Ab jetzt schreiben wir also nicht mehr:

sondern:

Da der MOVEQ-Befehl keine Unterscheidung zwischen Longs und Words macht, sondern immer die Werte auf Longs ergänzt, ist dieser Befehl besonders schmackhaft. Wenn wir ein Long-Datenregister beschreiben müssten, würden wir 12 TZ verschwendet. Durch Benutzung eines MOVEQ sparen wir 12 - 4 = 8 TZ und 4 Bytes!

Doch Vorsicht: Der MOVE-Befehl bewegt nur so große Werte, wie sie ihm angegeben werden. Es ist also das Long mit $ff000000 vordefiniert, und wir bewegen ein Byte ($ff) in das Register hinein, so hat es nach dem Bewegen den Wert $ff0000ff. Der MOVEQ allerdings löscht alles, was im Hi-Long steht. Da kaum Wörter oder Bytes bewusst ins Lo-Long-Datenregister geschrieben werden, und das Hi-Byte nicht zerstört werden darf, können wir meist getrost den Quicky benutzen.

Es sollte jetzt nicht mehr

heißen, sondern nun

Eine Einsparung von immerhin 4 Bytes und nach dem alten Spruch, „Kleinvieh macht auch Mist“, können wir gelegentlich schon ein paar Bytes sparen. Ich bin sicher, dass Compiler auf diese 4 Bytes unter keinen Umständen verzichten wollen.

Genauso wie es ein MOVEQ gibt, ist auch ein ADDQ, bzw. SUBQ vorhanden. Die Parallelen sind bei der Absolutquelle, der Unterschied jedoch bei dem Ziel. Das Ziel kann im Gegensatz zum MOVEQ, der nur Datenregister als Zieloperanden kennt, auch andere Adressierungsarten sein. Doch müssen wir hier mit einer (kleinen) Einschränkung leben. Unsere Quelle, also für den ADDQ/SUBQ der Absolutwert, darf nur zwischen 1 und 8 liegen. In den meisten Fällen ist damit aber auch zu leben.

So wollen wir auch nicht mehr

schreiben, sondern

Sollten wir einmal in die Lage kommen, den Absolutwert 10 zu addieren, so könnten wir leicht in Versuchung kommen, keinen Quicky anzuwenden. Doch halt! Neben den Ausführungszeiten gibt es noch die Programm-Länge, die es ebenfalls zu optimieren gilt. Bei einer Addition, die sich aus 2 Quickies zusammensetzen lässt, sollte der Quicky siegen, warum zeigt das Beispiel.

Aber es geht auch anders

Die Ausführungszeit für die beiden Quickies ist die gleiche wie bei der Ohne-Quicky-Methode (16 ZT). Doch benötigen wir nicht mehr 6 Bytes für die Addition, sondern nur noch 4. Eine kleine Optimierung, die auch zu kürzeren Programmen beitragen kann.

Bei dieser Adressierungsart wird der Operand entweder in das angegebene Register geschrieben oder aus ihm gelesen. Es stehen dazu alle Register von D0 bis D7 zur Verfügung.

Die allgemeine Syntax lautet: Dn

Es stehen dazu alle Register von A0 bis A7 zur Verfügung.

Die allgemeine Syntax lautet: An

Da es ab hier neu wird, ist es wichtig, die Funktionsweise dieser und folgender Adressierungsarten ein wenig zu erhellen.

In der Erklärung tauchte das Wort Zeiger auf, und vielleicht fragen einige, was das denn sein soll. Programmierer, die mit C oder Pascal vertraut sind, dürften mehr oder weniger schon wissen, was man mit diesen Zeigern machen kann. Der Name kommt daher, dass sie auf eine Speicherzelle zeigen. Wenn z. B. das Adressregister A4 die Adresse $10000 enthält, können wir den Sachverhalt auch mit folgenden Worten beschreiben. Der Zeiger A4 zeigt auf die Adresse $10000. Na und? Was haben wir davon? Nun, mithilfe dieser Adressierungsart ist es möglich, Daten, die an der Adresse stehen, auszulesen, zu bearbeiten, oder natürlich auch zu schreiben. Wollen wir doch einmal den Inhalt des Speichers der Adresse $1000 in ein Datenregister (D2) schreiben. Es soll nur ein Byte gelesen werden. Mit unserem bisherigen Wissen machen wir das wie folgt:

Aber, was ist, wenn die Adresse nicht bekannt ist? Schon ein Beispiel, warum die absolute Adressierung in manchen Fällen einige Probleme bereitet. Wir wollen daher die Zeile erneut schreiben, und zwar jetzt mit der indirekten Adressierung.

Anstatt ein move.l #xxxx,a0 kann man einen neuen Befehl verwenden, der Absolutwerte in Adressregister schreibt. Die neue Version sieht dann folgendermaßen aus:

Mit dieser Möglichkeit können wir auch einfach Daten verschieben

Nicht jeder Assembler achtet auf die geraden Adressen, die bei dem LEA-Befehl geladen werden. Sollte eine Adresse ungerade sein, wird spätestens bei der Ausführung die Rache kommen. Bei der Bewegung der Word wird ein Absturz folgen.

Bei der indirekten Adressierungsart mit Postinkrement ist das Adressregister ein Zeiger und dieser wird nach der Operation erhöht. Der Wert, um den das Adressregister erhöht wird, richtet sich nach der Operandenlänge. Wird ein Byte eingelesen, wird das Adressregister nur um den Wert eins erhöht, bei Word um zwei.

Es stehen dazu alle Register von A0 bis A7 zur Verfügung.

Die allgemeine Syntax lautet: (An)+

Die Features des Prozessors gehen noch weiter. In einigen Fällen wollen wir Daten, auf die die Adresse zeigt, auslesen, und die danach folgenden Informationen ebenfalls verwerten. Als Beispiel soll eine Tabelle angeführt werden, die Informationen über die Fenstergröße enthält. Dabei soll der erste Wert ins D0-Register geschrieben werden, und der nächste ins D1-Register. Die Tabelle enthält nur Words, ebenso sollen aus der Tabelle nur Words in die Register geladen werden. Der Zeiger auf Tabelle, nicht die Tabelle selber, soll in der Speicherstelle TabStart stehen.

Diesem Programm erlaubt es, Tabellen auszulesen. Der Addiere-Befehl muss hier sein, denn wir müssen den Zeiger auf das nächste Element springen lassen, und das ist 2 Bytes (1 Word) weiter.

Jetzt wenden wir unsere neue Adressierungsart an:

Das Ganze wirkt doch gleich viel übersichtlicher.

Indirektes kopieren

Doch auch Strings können über die indirekte Adressierungsart kopiert werden. A0 soll ein Zeiger auf einen String, und A1 soll der Zeiger auf den Puffer sein. Der String soll 7 Zeichen lang sein. Wir haben schon einmal eine Möglichkeit zur Stringverschiebung kennengelernt. Dies soll uns noch einmal bewusst werden.

Mit diesem Programmteil können String mit einer Länge von 7 Bytes kopiert werden, die Voraussetzung ist jedoch, dass die Adressen gerade sind, denn sonst droht wieder ein toller, roter, blinkender Kasten mit einer 3 drin. Der Trick ist wieder folgender. Wir nutzen die 4 Bytes Aufnahmekapazität der Longs. Was uns auch hier wieder auffällt, sind die Additionen, die je nach Länge der Übertragung natürlich verschieden sein müssen. (Einmal 4 Bytes und 2 Bytes). Zum Schluss brauchen wir nicht mehr einen hinzuaddieren, da der String kopiert ist, und die Adresse nicht mehr angepasst werden muss. Da es sehr regelmäßig vorkommt, dass Programme oder Strings kopiert werden müssen, wenn es gerade nicht der Blitter macht, würde immer in Addierbefehl zum Zeigen auf das nächste Datum benötigt werden. Der Prozessor aber kennt aber die Möglichkeit der indirekten Adressierung mit Postinkrement, die wir gerade kennengelernt haben. Der Vorteil liegt darin, dass der Additionsbefehl (2 Bytes und 4 TZ) gespart wird, und das immer die richtige Anpassung, d.h. Addition um auf das nächste Element zu kommen, jeweils um 4, 2 oder 1 ist.

Unsere verbesserte Programmversion sieht folgendermaßen aus:

Nachdem der Prozessor also die Daten mithilfe des Zeigers in das D0-Register transportiert hat, wird die Adresse um 4 erhöht, da es sich bei dem Zugriff um ein Long handelte. Wichtig ist, dass erst nach dem Bewegen der Daten die Adresse erhöht (inkrementiert wird). In der dritten Zeile wir die Adresse nur um Eins erhöht, da der Zugriff nur auf ein Word war.

Doch das unser Prozessor sehr mächtig ist, kennt er natürlich nicht nur die Möglichkeit über die indirekte Adressierung mit Inkrement in ein Datenregister zu schreiben, sondern auch als Ziel diesen Operanden zuzulassen. Das heißt, dass unser Programm wie folgt weiter verkürzt werden kann:

Toll nicht?

So sind auch einfache Zeichenumwandlungen möglich. Da wir die Schleifenbefehle bisher nicht kennen, vorab ein Pseudocode. Es soll A0 ein Zeiger auf eine Zeichenkette sein.

Bei der indirekten Adressierung mit Prädekrement ist das Adressregister ein Zeiger, und dieser wird entsprechend der Länge der in den Prozessor eingelesenen Werte vor der Verarbeitung vermindert.

Es stehen dazu alle Register von A0 bis A7 zur Verfügung.

Die allgemeine Syntax lautet: -(An)

Ebenso wie es eine Adressierungsart mit einer anschließenden Erhöhung der Adresse gibt, so ist auch eine Gegenadressierungsart vorhanden. Jetzt wird zuerst die Adresse vermindert, und dann wird auf sie zugegriffen. Die Reihenfolge ist vielleicht so zu merken, indem man auf die Stellung des Plus- bzw. Minuszeichens achtet. Da das Minuszeichen vor der geklammerten Adresse steht, wird sie zuerst vermindert und dann benutzt, im Gegensatz zum Pluszeichen, das erst nach der geklammerten Adresse steht, und diese dann erhöht.

Bei der indirekten Adressierungsart mit Adressdistanz und Index bildet die Summe aus Adressregister und einem 8 Bit Absolutwert sowie einen 32 Bit Index den Zeiger auf den Operanden.

D8 kann Werte zwischen -128 und 128 darstellen.

Es stehen dazu alle Register von A0 bis A7 zur Verfügung.

Die allgemeine Syntax lautet: D8(An,Rx)

Auch dieser Befehl eignet sich hervorragend für Tabellenarbeiten. Er erweitert die in 4.6.6 beschriebe Adressierungsart insofern, als er ein Indexregister erlaubt. Über diesen sind z. B. Zählschleifen möglich. Nehmen wir einmal an, wir haben wiederum eine Tabelle, auf die das A0-Register zeigt. An der Stelle 100, die unser D8 aufnimmt, stehen 12 Werte, die benötigt werden. Diese müssen bedauerlicherweise noch addiert werden. Was soll man tun? Unsere neue Adressierungsart hilft uns weiter.

Mit dieser Zeile, die wir in eine Schleife packen können, sind wir in der Lage, bei Benutzung des D0-Registers als Zähler von 1 bis 12, unsere benötigten Werte zu addieren.

Als Adressangabe dient ein Wort, das den Speicherplatz angibt. Die Werte sind Words, die dann auf Longs umgewandelt werden.

Die allgemeine Syntax lautet: #xxxx.w

Diese Adressierungsart wird am wenigsten genutzt. Außer um den Speicherbereich von 0 bis 65535 ($ffff) anzusprechen taugt der Befehl nichts. Da wir ohnehin in den meisten Fällen keinen Absolutspeicher gegeben haben, sondern nur den, den uns evtl. das Betriebssystem zur Verfügung stellt, ist der Befehl fast überflüssig geworden. Wenn wir allerdings betriebsystemfern programmieren, und uns die Speicherorganisation nicht mehr interessiert, können wir fleißig in den Bereich hineinschreiben, denn der Zugriff ist schneller.

Als Adressangabe dient ein Long, das den Speicherplatz angibt.

Die allgemeine Syntax lautet: #xxxx.l

Bei der indirekten Adressierungsart mit Adressdistanz bildet die Summe aus dem Programm-Counter und einem 16 Bit Absolutwert einen Zeiger auf den Operanden.

Die allgemeine Syntax lautet: D16(PC)

Die Anwendung der Adressierungsart ist gelegentlich zu finden. Sie bietet einige Vorteile bei der Variablenverarbeitung. Vorerst jedoch ein Zitat aus einem anderen Assemblerbuch: „Für die bedauernswerten Menschen, die trotzdem PC-Relativ programmieren möchten …​“. Programmiere ich also PC-Relativ, bin ich also bedauernswert, ach ja? Ich muss vorerst einmal einräumen, dass diese Adressierungsart durchaus nicht mit mehr Denkverarbeitung verbunden ist, denn bei normalen Programmen kommt hinter den Variablennamen nur noch (PC). Dies sieht dann etwa so aus:

Ich glaube, dass 4 Bytes Programmtext zu verkraften sind. Einen Nachteil dieses Befehls sehe ich nicht, und jetzt kommen wir zu den Vorteilen. Da „Wert“ eine Speicherstelle von 32 Bit darstellt, man aber bei der Relativen Programmierung meist keine großen Distanzen zwischen Programmzähler und Variablen auftauchen, wird zur genauen Speicherdefinition nur 16 Bit benötigt, eine Platzersparnis von 2 Bytes. Zudem ist PC relative Programmierung immer schneller als Absolute. Als Dritter Punkt wäre noch die interne Programmspeicherung zu nennen. Da das Amiga Betriebssystem ein Multitasking-System ist, das mehrere Prozesse (Programme, Tasks) quasi gleichzeitig ablaufen lässt, müssen alle Programme an jeder Speicherstelle laufen können. Das OS (Operation System, Betriebssystem) stellt den Speicher zur Verfügung (er organisiert ihn), wir können nicht davon ausgehen, dass sie immer an der selben Adresse laufen. Programme, die überall im Speicher stehen können, werden relokatibel genannt. Benutzen wir daher im Programm Absolutwerte, so werden diese aus dem Programm herausgefiltert und in einem Hunk, der vor jedem Programm zu finden ist, für den Computer verständlich abgespeichert. Durch diese Hunk-Liste kann er dann an jeder anderen Speicherstelle das Programm zusammensetzen. Benutzten wir eine PC-Relative Programmierung, so kann dieser Eintrag in die Hunk-Tabelle ausbleiben, das Programm wird also noch kürzer.

Ich wette, dass bei jedem guten Programm, das schnell ablaufen muss, PC-Relativ programmiert wird. (Man denke auch nur an den Cache!)

Für alle die, die sich nicht die Arbeit mit den „(PC)“ machen wollen, aber die Geschwindigkeit und kürze noch nachträglich in die Programme einbauen wollen, bietet der Devpac Assembler eine PC-Option p+ an, auf die wir aber später noch einmal zu sprechen kommen, wenn es darum geht verschiebbare Programme zu schreiben.

Bei der indirekten Adressierungsart mit Adressdistanz und Index bildet die Summe aus dem Programm-Counter und einem 16 Bit Absolutwert, sowie einem Index den Zeiger auf den Operanden.

Die allgemeine Syntax lautet: D16(PC,Rx)

Die Anwendung ist eine Mischung aus den obigen. Sie setzt sich zusammen aus der PC-Relativ Programmierung und der aus Kap. 4.6.7 (???). Die Anwendung ist hier dürftig, aber kann in manchen Fällen geschickt angewendet werden. Wiederum ist die Tabellenmöglichkeit, die als gutes Beispiel für die Anwendung vorausgeht.

Anstatt

lässt sich viel einfacher

schreiben. Dies ist kürzer und schneller. Wird jedoch der MOVE-Befehl in einer Schleife verwendet, und der A0 Zeiger nicht verändert, dann ist natürlich die erste Variante schneller, dass die Informationen über die Lage der Tabelle (Adresse) nicht erneut zur Verfügung stehen muss.

Man bezeichnet mit der Konstanten-Adressierung, oft auch unmittelbare Adressierung genannt, eine Möglichkeit, Absolutwerte (Konstantwerte) zu benutzen.

Es stehen dazu alle Register von D0 bis D7 bzw. A0 bis A7 zur Verfügung.

Die allgemeine Syntax lautet: #Rx

Wir haben in unseren früheren Programmen diese Adressierungsart schon kennengelernt. Sie muss bei Absolutwerten angewendet werden, wenn diese nicht im Speicher stehen. In vielen Fällen kann hier optimiert werden, zum Beispiel durch den MOVEQ-Befehl.

Die Und-Verknüpfung (auch Konjunktion oder Logisches Produkt genannt) soll die erste sein, mit der wir in den Katalog der Verknüpfungen einsteigen. Als Grundbeispiel sei auf eine einfache logische Schaltung verwiesen. Wir haben eine Lampe, die durch zwei in Reihe geschalteten Schalter gesteuert werden kann. Das Ergebnis kann nur ein Brennen oder ein nicht Brennen sein, nicht jedoch ein halbes. Es werden also zwei geschlossene Schalter zum Brennen der Lampe benötigt. Wenn einer der beiden Schalter nicht geschlossen ist, so bleibt die Lampe dunkel. Wir können also folgende Tabelle aufstellen.

Die Prädikate geschlossen und nicht geschlossen, sowie Lampe brennt und Lampe brennt nicht, lassen sich auch wie folgt in einer Tabelle darstellen. Dabei soll eine Funktion UND definiert werden, mit dem Zeichen „&“.

Da wir natürlich nicht nur ein Bit haben, sondern 8, 16 oder 32, so werden diese immer zusammen betrachtet. Unsere erste Long-Zahl soll z. B. %1111100010101000 und die Zweite %0101010111001101 sein. Dann liefert die Verknüpfung durch ein Logisches Und das Resultat:

Im Programm wir dies so aussehen:

Die Oder-Verknüpfung (Disjunktion) lässt sich auch mithilfe von Schaltern vorstellen. Im Gegensatz zum Und sind die Schalter jedoch parallel geschaltet, nicht in Reihe. Sollte also ein Schalter geschlossen sein, ein anderer jedoch nicht, so wird ein Signal vorhanden sein, da der Strom immer noch über den geschlossenen Kreis fließen kann.

Wiederum soll die Verknüpfung über eine Funktion definiert werden, die das Zeichen „+“erhält.

Unsere Bytes aus dem obigen Beispiel würden also mit der Oder-Funktion verknüpft folgendermaßen aussehen:

Die Exklusiv-Oder-Verknüpfung, in Programmiersprachen auch unter XOR bekannt, ist eine exotische Funktion. Sie löscht nur dann das Bit, wenn es in dem ersten Ausdruck genauso ist wie im zweiten Ausdruck – an derselben Position versteht sich. Wenn dies nicht der Fall ist, so wird das Bit gesetzt. Den genaueren Zusammenhang ist aus der Tabelle zu entnehmen.

Diesen Sachverhalt sollten wir wiederum an einem Beispiel klarmachen.

Die Negierung (Nicht) ist ein interessanter Befehl, der doch ziemlich simpel arbeitet. Er dreht einfach die einzelnen Bit um. Daraus folgt, dass aus jedem nicht gesetzten Bit ein gesetztes wird und umgekehrt. Somit benötigen wir nur eine Quelle. Ein

Beispiel:

Jetzt haben wir schon so viele tolle Register, da wird es manchmal schwer, auch alle zu benutzen. Doch nach einiger Zeit gewöhnt man sich an diese Tatsache (arm dran sind die, die Intel-PC-Assembler versaut sind), dass so viele Register zur freien Verfügung stehen, und wie wir sie alle benutzen. Und wenn einmal ein Programm steht, und alle 8 Register gnadenlos ausgenutzt werden, passiert es, dass sich die Registerinhalte im Weg sind, und einfach in falschen Registern stehen. Anstatt nun Koordinaten im D0 und D1-Reg. zu übergeben, kommt doch eine Routine so frech daher, und verlangt die Werte in umgekehrten Registern, also in D1 und D0. Tja, was nun bleibt, ist ein typischer Vorgang, gerade in höheren Programmiersprachen, die Variablen zu vertauschen. Die Definition einer Hilfsvariablen, oder eines Austauschregisters ist angesagt. Ein Register-Austauschprogramm mit dem Registerpaar D0 /D1 und dem freien Register D7 sieht dann so aus.

oder etwa

Um die Sache etwas schneller zu fabrizieren, deckten die Motorola Entwickler den Chip noch mit einem Register-Austauschbefehl ein. Er lautet EXG, und tauscht den Inhalt von zwei Registern 32-Bitig aus. Er kann in drei Kombinationen auftauchen:

Doch wollen wir einmal richtig kritisch sein, und überlegen: „Wann brauchen wir denn einmal einen Registeraustauschbefehl?“ Um der Lösung auf die Spur zu kommen, generalisieren wir zuerst einmal die Fragestellung und fragen: „Wann werden überhaupt Werte vertauscht?“ Ein sinnvolles Beispiel sind Sortierroutinen, denn dort werden Elemente ausgetauscht, wenn z. B. ein großes Element am Anfang der Liste steht, und gegen ein Kleines, das sich am Ende befindet, ausgewechselt werden soll. Doch Halt, nichts übereilen, denn wenn wir auf die Elemente der Liste zugreifen, verwenden wir meist eine komplexe Adressierungsart, und keine Datenregister. Schon sind wir mit unserem EXG-Befehl an der falschen Adresse, denn er unterstützt nur den Austausch von Registern, nicht von Speicherzellen. Da urteile ich doch schnell: „Tja Motorola, leider daneben entworfen. Wenn ihr schon einen Schritt voraus sein wollt, dann erlaubt einen Befehl wie z. B. EXG <EA>, <EA>, das wäre etwas Innovatives!“

Es ist toll, einen Rechner mit 32 Bit zu besitzen. Und dann noch 32-Bit Adressen, ho, ho, wer da noch aus alten Zeiten einen 64er programmierte, kann ein Lied von dem Speicherzugriff singen. Denn dort gab es noch nicht einmal 16-Bit-Register, die den Speichern adäquat ansprechen konnten. Damals musste man noch aus zwei 8-Bit Registern und indirektem Speicherzugriff auf flexible Adressen zugreifen. Ja, ja, das waren noch Zeiten. Aber auch ein PC mit veraltetem Prozessor, der ja nicht das Gelbe vom Ei ist, hat so seine Schwierigkeiten in Bezug auf die Speicherverwaltung. Gerade dieses Mischen von Word, Byte, und neuerdings auch Long-Adressen (mit neuerdings meine ich unsere PC-Freunde), hat man bisweilen so seine Problemchen. So machte man sich in der Motorola Werkstatt ran, einen Befehl zum Handhaben beider im 68000 zu implementieren. Der Befehl lautet SWAP und er kann Register-Hälften vertauschen. Doch was wird vertauscht? Da unser Prozessor 32-Bit Register zum Standard gemacht hat, bietet sich ein Vertauschen der höheren 16 Bit mit den niedrigen 16 Bit (oder auch umgekehrt, wie man’s nimmt) an. Der SWAP Befehl ist also ein vergleichbarer EXG, nur, dass nicht verschiedene Register vertauscht werden, sondern in einem Register die Highs und Lows.

Mit dem ASL-Befehl kann ein Register oder eine Speicherstelle um eine oder mehrere Stellen verschoben werden. Der LSL Befehl führt einen Logic-Shift-Left durch. Daher die Abkürzung LSL. Das folgende Beispiel macht die Arbeitsweise deutlich

Der Absolutwert %00001111 (Dezimal 7) wird um 5 Stellen nach links geschoben. Natürlich entsteht rechts ein Loch, welches aber mit Nullen aufgefüllt wird. Aus der 7 wird nun %11100000 (240). Wir können dies leicht beobachten, da es sich um Binärzahlen handelt, jedoch kann niemand einen Zusammenhang zwischen den Dezimalzahlen 7 und 240 vermuten, wenn er nicht die Bitmuster als Vergleichspunkt nähme.

Der LSR Befehl (Logical-Shift-Right) arbeitet ähnlich wie der LSL Befehl, jedoch hat dieser Links entstandene Lücken mit Null zu füllen.

Dieser Befehl unterscheidet sich nicht vom LSL Befehl.

Aus %10111011 (187) wird %11011000 (216)

Ich habe bei dem ASL Befehl stillschweigend gesagt, dass er derselbe sei wie der LSL Befehl. Aber geht denn das? Warum ist denn da kein Unterschied? Warum dann die Existenz dieses Befehls.

Ein Anstatt ist in der Historie und der Bedeutung der Abkürzung ASL bzw. ASR. Das „A“ am Anfang steht immer für „Arithmetic“, sodass die Abkürzung komplett für „Arithmetic Shift Left/Right“ steht. Vom LSL/LSR unterschieden sich die Mnemonics durch das „L“ der „Logic“.

Bei dem arithmetischen Schieben wird das 7. Bit als Füller genommen. Wenn beim logischen Verschiebevorgang von rechts nach links auf der rechten Seite Lücken entstehen, dann werden diese beim Lücken durch Nullen ersetzt. Nicht jedoch bei dem arithmetischen Verschieben nach rechts. Das siebte Bit ist ja bei Vorzeichen-Zahlen immer Indikator, ob die Zahl negativ (7. Bit gesetzt) oder positiv (7. Bit gelöscht) ist.

Ist das siebte Bit nicht gesetzt, so verhält sich der ASR-Befehl wie ein LSR-Befehl. Die Lücke wird durch Nullen gefüllt.

Aus %01010101 (85) wird %00101010 (42); kein Unterschied zu LSR.

Ist jedoch das siebte Bit gesetzt, so wird mit diesem gefüllt, d.h. nicht mehr mit Null, sondern mit eins.

Aus %10010111 (151) wird 11110010 (142); großer Unterschied

Da bei dem Verschieben nach Links das 7. Bit ohnehin wegfällt, kann dies nicht zur Betrachtung als Füllkörper herangezogen werden. Warum es ein ASL-Befehl gibt, kann ich mir nur so erklären, dass man zu dem ASR-Befehl ein Äquivalent wollte, den ASR-Befehl.

Bei den Rotationsbefehlen wird eine Seite nicht mehr mit Nullen aufgefüllt, sondern der herausfallende Teil kommt auf der anderen Seite wieder herein.

Aus %1110011 (230) wird %00110111 (55)

Rollen, nur nach rechts.

Aus %11110000 (240) wird %10000111 (135)

Mit Schiebebefehlen können wir in den meisten Fällen die Multiplikation mit Konstanten vermeiden. Wir wollen hier eine Reihe von Multiplikationen anführen.

Auf eine Reihe von Gegebenheiten muss allerdings geachtet werden:

Ich habe bei der Erstellung der Optimierungen immer eine Abkürzung genommen, um allgemein bei den Registern zu bleiben, wie z. B. Dx und Dx+1 (wie bei der MACRO-Definition), doch habe ich hier darauf verzichtet und verwende nur die Register D0, D1 und D2.

Multiplizieren mit 2

ist einfach möglich durch einmaliges Schieben nach links:

Anhand eines Bit-Beispiels ist dies vielleicht etwas deutlicher zu verstehen, warum denn ausgerechnet der Wert mit 2 multipliziert wird. Als Zahl soll die 13 dienen. Die Bitkombination sieht wie folgt aus: 13 = %0000001101. Nach Shiften ergibt sich: 26 = %0000011010

Da von Bit zu Bit immer um Zwei multipliziert wird, wird der Wert also verdoppelt. Apropos verdoppelt: wir erinnern uns, eine Multiplikation mit zwei kann auch als

geschrieben werden. Mithilfe der ADD- und LSL-Befehle will ich nun einmal einige Multiplikationen erklären.

Multiplikation mit 3:

Bei der Multiplikation mit 3 sichern wir die Zahl, und addieren sie zum Produkt mit 2.

Multiplikation mit 4:

Die Multiplikation ist durch zweimaliges Addieren, oder durch zweimaligen links schieben möglich.

Multiplikation mit 5:

Die Idee von der Multiplikation mit 3, dem sichern und aufaddieren finden wir in vielen ungeraden Zahlen wieder, so auch mit der Multiplikation mit 5, die die Zahl auf das Produkt mit 4 aufaddiert.

Multiplikation mit 6:

Auch mit der Multiplikation mit 6 ist es wichtig den Wert zwischenzusichern, allerdings nicht das Original, sondern die schon mit 2 multiplizierte Zahl. Der Trick liegt darin, die mit 2 multiplizierte Zahl auf die mit 4 multiplizierte aufzuaddieren.

Multiplikation mit 7:

Warum sollte man immer Additionen verwenden? Hier zeigt die Anwendung einen viel besseren Trick. Er lässt sich immer dann anwenden, wenn Zahlen, die um eins kleiner sind als eine 2^x-Zahl, multipliziert werden müssen. So z. B. bei der Multiplikation mit 7 oder auch mit 15 werden wir die Grund-Zahl einfach vom Ergebnis abziehen.

Multiplikation mit 8:

Dies ist einfaches Verschieben.

Multiplikation mit 9:

Als wir bei der Multiplikation sieben subtrahierten, werden wir hier natürlich addieren, auch ein Trick, der bei Zahlen 2^x+1 gilt.

Multiplikation mit 10:

Die Multiplikation mit 10 würde wieder wie bei der 6 zwei getrennte Additionen erlauben (8 und 2), doch ist dies zu langsam, und wir gehen wie bei der Multiplikation mit 9 vor, doch addieren wir noch einmal dazu.

Multiplikation mit 11:

Wie Multiplikation 10, nur noch ein ADD mehr, zeigt sich die elfte Routine.

Multiplikation mit 12:

Hier nutzen wir wieder den Zwischenspeicherschritt nach der ersten Multiplikation mit 4, denn nach der erneuten Multiplikation mit 2 sind wir schon bei 8, und 8 plus 4 sind 12 (letzte Zeile).

Multiplikation mit 13:

Wie 12, nur mit der Addition der originalen Zahl, die in D2 gesichert werden muss.

Multiplikation mit 14:

Wir multiplizieren erst die Zahl mit 2 (ADD) und sichern sie im D0-Register. Danach wird mit 8 multipliziert (wir erhalten als Ergebnis das Produkt mit 16), und die Subtraktion 16 - 2 ist 14:

Multiplikation mit 15:

Kennen wir schon, denn es ist die Strategie, die wir von Multiplikation mit 7 kennen.

Multiplikation mit 16:

Simpel durch schieben:

Multiplikation mit 17:

Wie immer mit aufaddieren

Multiplikation mit 18:

Multiplikation mit 19:

Multiplikation mit 20:

Multiplikation mit 40:

Multiplikation mit 640:

Die Multiplikation mit 640 kann sich wiederum in zwei Teile zerlegen lassen: Wir nutzen die Tatsache aus, dass 640 = 512 + 128 ist.

Resúmee:

Es fällt auf, dass sich Primzahlen nur sehr schwer optimieren lassen. Insbesondere bei größeren Zahlen, ist bei der Programmverschnellerung Köpfchen gefragt. Die Optimierung verlangt ein plastisches Vorstellungsvermögen, die Zahlen durch geschicktes Schieben und Addieren bzw. Subtrahieren zu bilden. Wer etwas üben will, der kann sich dran machen, Multiplikationen mit Primzahlen größer 100 zu entwerfen.

Zu bemerken ist, dass nach jedem Logischen, Mathematischen, Schiebe- oder Speichermanipulations-Befehl, der ausgeführt wurde, die Flags aktualisiert, d.h. gesetzt oder gelöscht werden. Diese Information ist essenziell, denn sie erspart in vielen Fällen ein neues Überprüfen der Register oder Speicherzellen auf Ereignisse.

Mit bedingen Sprüngen kann der Computer auf die Resultate der Flags mit bestimmten Absprüngen regieren. D.h.: Wenn ein Flag gesetzt ist, kann durch einen Sprungbefehl ein entsprechender Absprung getätigt werden. Andersherum: Wenn das Flag nicht gesetzt ist, bleibt ein Absprung aus.

Der Befehl, der die Sprünge einleitet, ist Bcc. „cc“ bedeutet hierbei „Condition Code“, und es bezeichnet die Statuswerte. Da jedes Anwenderbit abgefragt werden kann, existieren auch verschiedene cc’s. Wenn wir überprüfen wollen, ob eine Zahl gleich Null ist, also das Nullbit im SR gesetzt ist, so können wir dies mit cc „eq“ machen. Der Befehl lautet dann BEQ. Nach diesem Bedingtem-Verzweige-Befehl folgt eine Sprungadresse, die, falls die Bedingung erfüllt ist, angesprungen wird. Ist die Bedingung nicht erfüllt, so erfolgt kein Sprung. Die cc’s sind in der Tabelle einmal zusammengefasst.

Zu beachten: Bei allen Sprüngen werden die einzelnen Flags nicht verändert.

Buchstaben von Groß nach Klein

Nehmen wir einmal an, wir hätten ein kleines Unterprogramm geschrieben, welches überprüft, ob wir kleine oder große Buchstaben haben. Mit Hilfe dieser Information soll ein weiteres Unterprogramm angesprungen werden, welches die kleinen Buchstaben in Große umwandelt. Falls der Buchstabe, der in die Funktion als Argument einging, ein Kleiner ist, soll als Ergebnis eine -1 (Logisches Ja) im D0-Register übergeben werden. War der Buchstabe schon ein großer, so soll eine Null (Logisches Falsch) übergeben werden. Nun kann mithilfe der BEQ (sprich: „branch equal“) und BNE („branch not Equal“) Befehle das Ergebnis ausgewertet werden, und z. B. bei einem gelöschten Null-Bit eine Routine zum Umwandeln aufgerufen werden, währenddessen bei einem gesetzten Null-Bit (Großer Buchstabe) die Umwandlungsroutine übersprungen werden kann. Ein Teilprogramm könnte so aussehen.

Immer wieder kommt es vor, dass ein Nullbyte erkannt, und demnach auch verzweigt werden muss. Da Strings heutzutage immer mit Nullbyte abgeschlossen werden, wäre ein cmp.b #0,ea ziemlich langsam und lang. Der Befehl kostet 2 Bytes Kennung und weitere Bytes für die binäre Null. 2 Bytes für das Null-Byte bzw. -Word und 4 Bytes für das Long. Alles dafür, dass etwas mit dem Nullbyte verglichen werden soll? Das Nullbyte ist ein Sonderfall unter allen vorkommenden Zahlen, es ist einfach Nichts. Und daher nimmt es eine Sonderstellung ein, und es wurde ein neuer Befehl zum Vergleich mit dem Nichts erschaffen. Der TST-Befehl. Er braucht im Gegensatz zu dem CMP-Befehle keine Quelle, spart also hier schon einmal 2 oder 4 Bytes. Intern wird einfach geprüft, ob irgendein Bit ungleich Null ist. Wenn das Resultat Null ist, so wird das Zerro-Flag gesetzt, ansonsten gelöscht.

Wie schon erfahren, werden die Flags nach fast jedem Befehl aktualisiert. Wollen wir jedoch nachträglich ein Flag gesetzt haben, so müssen wir dies mit dem TST-Befehl machen, durch diesen Befehl werden die Flags neu gesetzt. Das kann insofern günstig sein, als dass wir ein Unterprogramm aufrufen, und von ihm einen Wahrheitswert zurückgekommen. Vielleicht wird danach mit einer kleinen Addition die Flag-Inhalte zerstört. Mit dem TST Befehl kann der Zustand wieder hergestellt werden, wenn wird das Ergebnis des Unterprogramms wieder benötigen.

Flags in der Betriebssystemprogrammierung

Ein Beispiel aus der Betriebssystemprogrammierung zeigt, wie die Flags hier eingesetzt werden, und abgefragt werden müssen.

Das folgende Beispiel öffnet eine Library. Wir können den kurzen Programmausschnitt durch Ausnutzen der Flags wunderbar optimieren.

Leider darf so ein Programm nie optimiert werden. Alle OS-Unterroutinen übergeben neutrale Flags, die also nicht mit dem Übergabeparameter zu tun haben müssen. Der TST-Befehl müsste also rein, oder? Nein! Dass es noch anders geht, zeigt das folgende Programm:

Wenn D0 nach A0 bewegt wird, werden die Flags gesetzt.

Stringlänge

Ein häufiges Problem ist die Stringlänge. Doch mithilfe des TST-Befehls können wir diese leicht ermitteln, da wir nur bei einer Zahl ungleich Null, die ja ein normales Zeichen repräsentiert, verzweigen, und einen Zähler um einen erhöhen.

Die Arbeitsweise ist einfach. Unser Zählregister ist das D0-Register. Danach betreten wir schon den Bereich der Schleife, die mit einem Addiere-Befehl eingeleitet wird. Unsere Stringlänge ist also schon einmal mindestens eins, auch wenn der String keine Zeichen enthält. Nach der Erhöhung kommt der Test-Befehl, und die nachfolgende Zeile verzweigt, falls D0 ungleich Null, dem Endezeichen war. Bei Ablauf und Finden des Null-Bytes muss natürlich noch der zu früh erhöhte Zähler, das Überbleibsel aus dem Schleifeneingang, um eins vermindert werden. Ist dies getan, so haben wir in D0 unsere Stringlänge.

Für die Optimierung gilt das gleiche wie für die Optimierung von anderen Befehlen auch. Doch hier zieht ein Absolut-Lang-Word Vergleich (14 TZ) schon viel mehr rein, als z. B. ein Word Vergleich (8 TZ). Daher wenden wir schon wieder einmal an, was wir eigentlich bereits wissen. Wir Move-Quicken ein Long (leider dann begrenzt) in ein freies (!) D-Register (4 TZ) und vergleichen dies mit dem anderen Wert (6 TZ).

Nicht

sondern

Und wenn auch nur irgendjemand einen cmp.(Typ) #0,ea verwendet, den sollte man …​

Kommen wir nun zu dem ersten Befehl unserer Serie. Der Aufruf lautet:

Die Bitnummer kann ein Absolutwert sein. Falls man variabel sein will, kann dort auch in einem Register stehen.

Die Zeiten dieses Befehls haben es in sich, so kostet eine einfache Operation in der Grundausstattung schon 8 TZ (natürlich mit einem Datenregister). Doch mit einem Absolut Long sind wir schon 16 TZ los. (Schluck!)

Nehmen wir einmal an, wir wollten Bit 2,3 und 5 in der Speicherstelle $1234 setzen. Der Aufruf lautet:

Dieser Abschnitt kostet uns 20 * 3 = 60 Taktzyklen. Es handelt sich bei $1234 um ein Word, also nutzen wir dies auch.

Bitset ist oft zu langsam

Da wir hier immer dieselbe Adresse haben, können wir auch verkürzter schreiben:

Wir kommen immerhin schon auf 8 + 12 * 3 = 44 Taktzyklen runter. Doch kommt es bei guten Programmen ohnehin nicht vor, dass jemand mehrere Bit mit dem BitSet-Befehl setzt. Viel besser ist es, sie durch die schon oben genannte Methode, die der Verknüpfung, zu setzen. Kürzer lässt sich der Sachverhalt so formulieren:

Dies kostet nur noch 20 Taktzyklen, was aber immer noch eine Menge ist. (Zuviel würde ich sagen). Und auch eine Benutzung des Datenregisters bringt keine Vorteile, denn wir benutzen nur Words, nicht aber Longs zur Verknüpfung.

Der BitClr-Befehl ist äquivalent zu dem BitSet-Befehl, nur das er Bit löscht. Auch hier ist ein schnelleres Und-en schneller, da dieser logische Befehl schnell mehrere Bit löschen kann.

Es sind die Bit 5 und 6 des D0-Registers zu löschen.

Schneller wäre hier wiederum ein Logik-Befehl

Der Bit Change Befehl ist ein recht seltener Befehl. Er besitzt die Fähigkeit, Bit umzudrehen. Ist ein Bit gesetzt, wird es gelöscht, und ist es nicht gesetzt, wird es gesetzt. Natürlich gibt es hier wieder einen Ersatzbefehl, der die Sache wieder um ein Vielfaches beschleunigt. Welcher ist das wohl?

Wollten wir das vierte Bit im D4-Register umdrehen, dann würden wir folgendes schreiben, und aus einem gesetzten wird ein gelöschtes, und umgekehrt.

Der Bit-Test Befehl ist am schwierigsten umzuschreiben. Mit ihm kann man einzelne Bit abfragen.

Ist das abgefragte Bit nicht gesetzt, so ist das Null Flag gesetzt, einfach zu merken, denn ist im Bit nichts, so ist auch das Null-Bit gesetzt, da Null ja auch nichts ist.

Maustaste

Eine Anwendung des Befehls wäre z. B. die Abfrage von Hardware Registern. Das Bit 6 der Speicherstelle $bfe001 gibt etwa an, ob die linke Maustaste gedrückt wurde.

Dieses Miniprogramm wird noch häufiger verwendet.

Interrupts sind bei dem C-64 schon immer ein Schlagwort in der Demo- und Spiele-Programmierung gewesen. Doch warum sollten besonders sie so wichtig sein?

Interrupt ist das englische Wort für Unterbrechung, und da haben wir schon das Wichtigste, es wird unterbrochen, und zwar das laufende Programm. Ein Interrupt stört ein ablaufendes Programm, und in der sogenannten Interrupt-Routine wird ein kleines anderes Programm ausgeführt. Die Signale, die Interrupts auslösen können, sind verschieden, und sind auch alle für verschiedene Zwecke einsetzbar. Nehmen wir einmal als Beispiel den Interrupt, der ausgelöst wird, wenn oben eine Rasterzeile anfängt den Bildschirm zu beschreiben. Das Interruptprogramm kann jetzt auf eine bestimmte Zeile warten, und dann z. B. die Farbe oder Auflösung ändern. Das Tolle dabei ist: Das Hauptprogramm weiß gar nichts von dem Interrupt, es arbeitet einfach weiter. Hier haben wir den ersten Vorteil: Abarbeitung von Programmen, die natürlich nicht zu lang sein dürfen, ohne dass das Hauptprogramm gestört wird. Noch ein anderer Vorteil ist mit der Ausführung verbunden: die Gleichmäßigkeit der auslösenden Signale. Besonders bei Musikprogrammen ist es wichtig, dass die Unterbrechung gleichmäßig kommt, sodass bei der Musikabspielung kein Leiern entsteht.

Da der Benutzer viele Interrupts selber in das Programm integrieren kann, gibt es einen Interrupt-Server. Dieser übernimmt dann die Abarbeitung, und überprüft, dass kein Interrupt zu kurz kommt.

Um ein Interrupt in das System einzubinden, muss eine Interrupt-Struktur angelegt werden. Sie ist sehr kurz (gerade einmal 22 ($16) Bytes).

Diese Struktur muss nun einer Exec-Funktion übergeben werden, die diesen Interrupt dem System-Server hinzufügt. Die Routine heißt

Wird vom System ein bestimmter Interrupt erzeugt (z. B. Rasterzeile oben), so wird eine zugehörige Routine abgearbeitet. Welcher Interrupt dies sein soll, wir können ja nicht bei jedem Interrupt unser Programm abarbeiten lassen, wird in IntNr (Register D0) übergeben. Löst das System nun einen Interrupt der Nummer IntNr aus, so wird unser Programm abgearbeitet. Natürlich gibt es auch hier Prioritäten, diese werden in der Interrupt-Struktur eingetragen.

Nach dem Aufruf ist der Interrupt aktiv, und unsere Routine wird immer beim Auslösen aufgerufen. Um den Interrupt wieder zu entfernen, muss er aus der Interrupt-Server-Liste wieder gelöscht werden. Dies übernimmt die Exec-Funktion RemIntServer(). Die Parameter sind analog denen von AddIntServer().

Interessant ist, dass bei AddIntServer() kein Handle mitgegeben wird, sondern für das Abmelden auch ein Zeiger auf die Original-Struktur vorhanden sein muss. Der Interrupt wird also nicht vom System kopiert! Das kann schwerwiegende Konsequenzen haben, wie wir im nächsten Kapitel erfahren können.

Das folgende Listing führt einen Farbwechsel durch. Das Programm wird im Rasterstahl-Interrupt, IntNr=5, ausgelöst.

Das Hauptprogramm besteht aus dem Aufrufen von IntStruktAufbauen sowie InitInterrupt, einer Warteschleife und aus dem Aufruf von EndInterrupt.

In dem ersten Unterprogramm wird eine Interrupt-Struktur aufgebaut. Freien Speicherplatz haben wir daher am Programmende mit der Zeile: „IntStruct ds.b 22“ belegt. In diesen Speicherbereich bauen wir jetzt eine Struktur auf. Nur wenige Einträge sind nötig. Den Zeiger auf den Interrupt-Code müssen wir eintragen, und vielleicht noch die Priorität, aber auch das könnte man sich eigentlich sparen. Jetzt steht die Struktur, und der Interrupt kann ins System eingebunden werden. Die IntNr ist 5, was für einen Rasterzeilen-Interrupt steht. Bei jedem Erreichen der ersten Bildschirmzeile durch den Rasterstahl wird ein Interrupt ausgelöst. Das Aufrufen von AddIntServer() bindet die Struktur in die Liste ein. Jetzt wird bei jedem Durchlauf unser Programm aufgerufen. Es ist ein einfaches Programm. Wir sichern Register und Statusflags, und können dann das Unterprogramm Farben aufrufen. Aus der Speicherzelle $dff006, die die aktuelle Rasterzeile angibt, übertragen wir den Wert in das Hintergrundfarbregister. Damit haben wir immer unterschiedliche Farben auf dem Schirm.

Dieses Farbgeflimmere läuft jetzt im Hintergrund, und das Programm wartet nun auf einen Druck auf die Maustaste. Ist dieser getätigt, wird das Unterprogramm EndInterrupt aufgerufen, damit wird der Interrupt aus dem System entfernt.

Das Amiga OS ist ein Multitasking Betriebssystem. Multitasking heißt, mehrere Programme können quasi gleichzeitig abgearbeitet werden. Effektiv kann natürlich nur ein Programm real laufen, wir haben ja auch nur einen Prozessor. Exec schaltet in einer Interrupt-Routine die Programme um. Dazu müssen sie sich in einer speziellen Form befinden. Die Programme, die von Exec verwaltet werden, heißen Tasks (engl: Aufgabe). Tasks haben ein genormtes Bild, das es einfach macht, sie zu switchen (umzuschalten). Dieses Umschalten wird auch Task-Switching genannt.

Eine Library, oder in der Übersetzung Bibliothek, ist eine Sammlung von Funktionen. In der Bücherei kann man zu fast jedem Gebiet ein Buch finden, so sollte es mit den Libraries auch sein, sie sollten zu jedem Problemgebiet eine Betriebssystemfunktion anbieten können. Was ist, wenn in der Bücherei einmal kein Buch zu einem Thema vorhanden ist? Übertragen wir dies auf die Programmierung: Zu einem ganz speziellen Gebiet existiert keine Funktion. Dann sollte mit anderen Funktionen das gesuchte Problem gelöst werden, nicht aber etwas erfunden werden, was bisher nicht aufgeschrieben wurde. Oder, wir leihen uns ein Buch aus, was übertragen auf den Computer einer externen Implementierung gleichkommen würde.

Mit der Exec-Library haben wir eine leistungsstarke Library kennengelernt, die sich um die Verwaltung des Speichers, die Interrupts, die Tasks und noch einiges mehr kümmert. Die Exec-Library ist aber dennoch ein Sonderfall, denn sie ist durch die absolute Adresse $4 sofort ansprechbar. Dies ist bei anderen Libraries nicht so. Aber, was gibt es denn da noch so für Libraries? Die folgende Tabelle soll eine kleine Übersicht über Librarynamen und Funktion bieten.

Hinzu kommt noch eine ganze Menge mehr. Es hat sich z. B. unter OS 2.0 die Anzahl verdoppelt. Zudem kommt eine gewaltige Menge externer Libraries auf dem PD-Sektor hinzu.

Die in der Tabelle genannten Libraries sind alle intern, d. h. sie müssen nicht erst von Diskette geladen werden. Interne Libraries sind in das ROM verlagert worden, da die Funktionen oft benötigt werden. Externe Libraries enthalten Funktionen, sie seltener benötigt werden, und wofür ROM-Plaz zu schade war.

Ein Device ist eine Ebene zwischen Hardware und Library, die Daten austauscht. Devices haben eine große Ähnlichkeit mit Libraries, auch sie enthalten viele grundlegende Funktionen, die der Benutzer nutzen sollte. Bei genauerer Betrachtung des ROM-Listings zeigt sich, dass sie die gleichen Funktionen zur Tabellengenerierung nutzen.

Einen wesentlichen Unterschied zur Library gibt es allerdings doch. Nach dem Öffnen der Library steht eine initialisierte „Ebene“ zur Verfügung, dies ist bei Devices nicht so. Hier geschieht der Datenaustausch über Strukturen. Die wichtigste Struktur ist hierbei IORequest. Exec verfügt daher über viele Funktionen, die die Kommunikation mit Devices und deren Strukturen vereinfachen und sogar erst ermöglichen.

Die nachfolgende Tabelle enthält die wichtigsten Amiga-Devices:

Eine der wesentlichen Aufgaben des Computers ist es, Daten zu verarbeiten. Die Daten, die jedoch zum Bearbeiten herangezogen werden, müssen aber irgendwie verfügbar sein. Einige Programme haben dazu Schnittstellen in Form einer Textzeile, um die Informationen einlesen zu können. Jedoch dürfe das auf die Dauer etwas anstrengend werden, wenn die benötigten Daten immer neu eingetippt werden müssen. Der Computer muss die Daten also speichern können. Dies geschieht mit Hilfe der Dateien, die die Informationen aufnehmen. Dabei sind die Daten sequenziell hintereinander angeordnet. Die Dateien, englisch files genannt, werden auf Festspeicher gesichert. Die DOS-Library hat nun die Aufgabe, eine Verbindung zwischen den Dateien und den Medien zu schaffen. Der Benutzer, der über ein CD-Laufwerk verfügt, muss sich genauso wenig über das Speicherverfahren kümmern, wie der Benutzer eines Laufwerkes. Die Art und Weise übernimmt also alleine das DOS. Die Routinen, die das DOS zur Kommunikation mit den Dateien bietet, sind also ziemlich allgemein gehalten, reichen jedoch zum Arbeiten völlig aus.

Nun soll unser Ausgabeprogramm um einige Features erweitert werden. Häufig ist es störend, dass ein neues Fenster geöffnet wird. Nehmen wir das obere Programm und compilieren es, und führen es auf dem CLI aus. Obwohl schon ein Fenster geöffnet ist, erscheint ein neues. Das ist in den meisten Fällen ärgerlich, und für die Ausgabe kleinen Meldung, die z. B. die Parameterübergabe als Info auf dem Schirm bringen, überflüssig, und es wäre völlig ausreichend und wünschenswert, dass sie in dem Fenster erscheinen, aus dem gerade das Programm aufgerufen wurde. Das OS bietet daher eine kleine Besonderheit, und zwar, auf das gerade geöffnete Window zugreifen zu könne. Mit einem kleinen Sternchen ist dies machbar: anstatt der CON:…​.-Zeile erscheint nur einfach * als Fensterdefinition. DOS nimmt also automatisch das aktuelle Fenster, und gibt dort die Meldungen und Text aus.

Das Programm soll langsam zu einem kleinen TYPE-Befehl heranwachsen. Jetzt allerdings soll erst einmal ein Textfile geöffnet werden, und aus diesem 300 Byte gelesen werden. Diese werden in Puffer gesichert, und anschließend über den Write-Befehl im Fenster ausgegeben. Das Programm hat wiederum große Ähnlichkeit mit den schon beschriebenen, viel zu sagen gibt es hier nicht.

Wenn wir unseren TYPE-, LIST- oder DIR-Befehl nehmen, bei allen fällt auf, dass die Ausgabe auf ein Fenster erfolgt. Wie wir nun wissen, können wir dies allerdings auf eine Datei umlenken. Doch in unseren obigen Programmen erzwingen wir immer eine Ausgabe auf einem Window, oder als Sonderfall im aktuellen CLI-Window. Doch was ist nun, wenn der Benutzer nicht an die Meldungen interessiert ist, und sie z. B. mittels NIL: ins nichts, mit SER: an andere Computer, mit PRT: an den Drucker, oder sogar mit SPEAK: an den internen Laberkopp schickt? Dann ist unser Programm aufgeschmissen, und auch der uninteressierteste Programmuser bekommt unsere Meldungen.

Doch damit dies nicht geschieht, und aufwendige Abfragen nötig werden, greift uns unser Betriebssystem ein wenig unter die Arme. Es Existiert in der Dos.Lib einen Befehl namens Output. Er wir ohne Übergabeparameter mit dem Offset -60 aufgerufen, und holt uns unsere Datei-Indentifikation herein, die im Augenblick als Ausgabedatei definiert ist. Dies ist natürlich wunderbar, und da die Standartausgabe meist im CLI-Fenster abgeht, ersparen wir uns so ein Öffnen des Window, denn Output lieft uns sofort einen Handle im D0-Register zurück. Eigentlich eine sehr nützliche Funktion. Wenn man ganz sicher gehen will, das die Ausgabe in ein Window gehen soll, so muss man zwangsläufig ein DOS-Fenster selber öffnen. Doch die Output Funktion liefert die idealen Parameter, da auch gewünschte Ausgaben an die betreffende Stelle, wie z. B. Drucker, sofort und einfach über ein Handle möglich ist.

Das Unterprogramm FindeDatInfo ist hierbei der Informationsgeber, denn in diesem wird die Output Funktion aufgerufen. Wieder zurück im Hauptprogramm wird mittels eines TST-Befehls wieder bei einem Fehler verzweigt. Ging alles klar kann das Unterprogramm Schreiben in Aktion treten. Es gibt den Text, stehend an TextAnf, mit der Länge TextEnd-TextAnf nun mittels dem FensterHandle aus. (Wir hätten den Handle auch DruckerHandle nennen können, wenn die Ausgabe meistens an den Drucker läuft. Ich habe hier nur FensterHandle genommen, da es sich fast immer um ein Fenster als Ausgabemedium handelt.) Ist die Ausgabe beendet, so wir die Dos-Lib. geschlossen, aber seltsamerweise nicht unsere Datei. Das dürfte allerdings einleuchten, warum nicht. Es handelt sich ja um eine schon bestehende Datei, wenn wir es einmal so nennen wollen, und auf diese greifen wir nun zu. Und da wir sie auch nicht öffnen, sondern uns nur einen Zugriff erlauben, wir diese Datei auch nicht geschlossen.

Bestimmt grinste einem schon einmal eine bunte, schräge, unterstrichene, dicke, inverse Schrift an. Das Geheimnis dieser Schrift Styles ist, kann einfach gelüftet werden. Das RAW-Fenster. In diesem Fenster, das im Gegensatz zu dem Console-Fenster steht, kann neben ganz normalen Textausgaben auch Steuerzeichen übersandt werden. Alle diese Sequenzen, wie sie genannt werden, sind mit einem Einleitungszeichen versehen. Dieses Zeichen, mit dem Hex-Wert $9B, wird auch "Control Sequence Introducer", oder kürzer CSI genannt. Die nun folgenden Zeichen bewirken die Funktion, wobei noch Dezimalzahlen, gekennzeichnet mit n, auftauchen können. Eine Liste der wichtigsten Sequenzen ist in der nun folgenden Tabelle gegeben.

Andere Sequenzen wirken wie:

In der Tabelle finden wir viele Sequenzen, die für den Umgang mit dem CLI sinnvoll sind. Der Ursprung der meisten Codes ist historisch zu sehen. Als es noch Terminals gab, vergleichbar mit Telex, musste durch eine einfache Ansteuerung eine Wirkung auf dem Schirm erfolgen, quasi eine Art Programmiersprache für Zeichensetzung.

Mit dem folgenden Programm will ich demonstrieren, wie die Ausgabe im Praktischen aussieht. Um sich die Arbeit einfach zu machen, und nicht immer $9b…​. zu schreiben benutze ich Makros, die dann an den entsprechenden Positionen eingesetzt werden.

Vieles ähnelt dem vorigen Programm, was hinzukam sind die Makros und der veränderte Text.

Nun wollen wir aber richtig in die CLI-Tool Box einsteigen. Wir wissen ja, dass das OS uns einen Zeiger auf die CLI-Übergabe-Zeichenkette in A0 übergibt, und damit kann man schon etwas anfangen. Unser Programm STIL soll dazu dienen den Zeichensatz-Modi zu ändern. Dies ist zwar völlig hohl und Panne, da es über CLI natürlich auch geht (wir machen es ja nicht anders), jedoch ist ein Programm immer übersichtlicher und sowieso schöner, wenn so etwas in einer startup-sequence auftaucht.

Der ECHO-Befehl dürfe allgemein bekannt sein. Unsere jetzige Aufgabe soll es sein, einen einfachen ECHO-Befehl nachzuschreiben. Dabei setzen wir unser ganzes Optimierer-Wissen ein, um eine möglichst kurze Version zu haben.

Bei dem Programm machen wir uns wieder zu nutze, dass der Übergabestring in A0, und die Länge diesen in D0 steht. Wir kopieren einfach die Register nach D2 und D3, denn sie werden bei dem OS-Aufruf OpenLibrary() und Output() nicht zerstört. Und da haben wir sie ja gleich in den richtigen Register, wo wir sie für Write() haben wollen. Besser kann es ja nicht kommen.

Passt es, oder passt es nicht? Gerade bei 512 KB machen sich einige Leute noch Gedanken, ob das Programm nun bei drei Editoren und fünf Uhren noch in den Speicher passen. Für diese Sorte Mensch ist unser Programm AvailMem bestimmt das richtige, denn es wird der verfügbare Chip/Fast und TotalRAM greifbar sichtbar gemacht. Natürlich werden machte erst zögern und denken, „Oh Schreck, oh Graus, eine ASCII-Zahl-Wandel-Routine wird benötigt!“, doch halt, man denke an die geniale RawDoFmt() Funktion, die uns dabei die Arbeit abnimmt. Und unter so wenig Aufwand programmieren wir ein 244 Byte langes Mem-Anzeige-Tool.

Zuerst einmal holen wir uns über die Exec-Funktion AvailMem() den verfügbaren Speicher. Drei Speicher-Kategorien werden von uns abgefragt. Die Spezialisierung auf eine bestimmte Speicherart war ja durch Festlegung von D2 möglich. Den freien Chip-RAM (durch 2 oder 3) schreiben wir in ChipFree, FastRAM (4 oder 5) in FastFree und den gesamten Speicher (0 oder 1) in TotalFree.

Im nächsten Schritt muss der Ausgabestring erstellt werden. Auch bei der maximalen Speicherbelegung wird die Länge des effektive Textes 120 Zeichen nicht überschreiten. Wir besorgen also 120 Bytes, und mit dem Zeiger auf den freien Speicherblock in D0 werden wir durch bewegen nach A3 diesen gleich weiterverwenden. Die Funktion RawDoFmt() generiert mit dem Formatstring Text und den Daten einen String. Diesen geben wir wie gewohnt über den Output-Handle aus. Zum Schluss dürfen wir nicht vergessen, den belegten Speicher wieder freizugeben. (Sonst fehlt er uns nachher nach 4000 Aufrufen!)

Der Amiga ist schon immer ein reiner Grafikcomputer gewesen. Doch warum Grafikcomputer? Ist Grafik denn nicht eine Eigenart, die jeder Rechner beherrscht? Nein, dies noch lange nicht. In früheren Zeiten war Grafik eine Seltenheit, Textschirme waren da die Regel. Dies lag am unzureichenden Speicherplatz der damaligen Systeme. Eine Grafikseite kostet viel Platz, und dieser Platz war wertvoll, zu wertvoll, um ihn zu “verschwenden“. Eine Textseite bestand nur als Textzeichen, z. B. in der Größe von 80 * 25. Wenn für jeden Buchstaben ein Byte einkalkuliert würde, so wäre der notwendige Speicherplatz lediglich 80 * 25 = 2000 Bytes groß, lächerlich für heutige Verhältnisse. Eine entsprechende Grafikseite mit einer Buchstabenbreite von 8*16 Pixel nimmt dann schon 80 * 26 * 16 = 16 * 2000 = 32 kb ein. Nicht umsonst weichte man wenn möglich auf Textseiten aus. Doch es gibt noch einen anderen Grund, der nicht zu verachten ist. Arbeitet der Rechner nur mit Grafikseiten, dann muss das System schnell genug sein, um die Zeichen ausreichend zügig darzustellen. Bei Text-Seiten übernimmt die Hardware die Zeichendarstellung, ein Byte, ein Zeichen, bei Grafikseiten, ein Byte gerade einmal ein Sechzehntel. Wenn man Vergleiche zum C-64 zieht, so muss man sagen, dass dort eine gelungene Kombination zu finden ist. Auf der einen Seite der Textbildschirm für schnelle Ausgaben, und auf der anderen der Grafikschirm für Spiele und hochauflösende Anwendungen. Benutzer des GEOS werden es merken, die Geschwindigkeit ist sehr gering.

Mit dem Amiga wurde ein Computer auf den Markt gebracht, der schnell genug war, die anfallenden Grafikdaten zu verarbeiten. So hilft der Blitter mit, Text auf dem Schirm darzustellen, überhaupt ist der Blitter wesentlich mitverantwortlich für das gelingen des gesamten Systems.

Wie könnte es auch anders sein, die Grafikfunktionen sind wieder in einer Library organisiert, die graphics.library. Sie ist natürlich intern, und muss nicht nachgeladen werden. Dabei ist sie sehr groß, eine Menge Funktionen werden unterstützt. Es ist möglich, dass einige Programmierer Funktionen vermissen werden, doch zur Diskussion werde ich an anderer Stelle noch kommen.

Wie die Intuition- oder Exec-Lib kann sie in Bereiche unterteilt werden, die folgend aufgelistet sind. Im Verlauf dieses Kapitels werden wir fast ausschließlich Funktionen von Punkt eins kennenlernen.

Konzentrieren wir uns auf die Zeichenoperationen im Rastport. Doch, was ist eigentlich ein RastPort? Dieser Frage gehen wir in auch in diesem Kapitel, jetzt soll es erst einmal reichen, dass der RastPort eine Datenstruktur ist, die Einträge wie Farbstift oder Zeiger auf die Bitplanes enthält. Wer sich noch erinnert, wir haben den RastPort auch schon mal verwendet, als wir nämlich mit Intuition Grafikfunktionen ausführten. Wir können jetzt die Grafikfunktionen aus Intuition erweitert denken, nur, das die Routinen jetzt in der graphics.library zu finden sind. Der Begriff RastPort ist also gar nicht mehr so neu.

Jeder der Grafikausgabefunktionen muss ja wissen, wohin die Grafik kommen soll, es ist nicht so, dass wir einfach wild auch den Schirm malen können, es gibt ja noch so was wie Clipping. Also übergeben wir den Funktionen alle im A1-Reg. ein Zeiger auf den RastPort, der das Fenster oder das Window kennzeichnet. Er ist bei einem Fenster der Window- Struktur zu entnehmen. Das sieht dann etwa so aus.

Äquivalent sieht die Sache bei einem Window aus. Ist es geöffnet, so liegt der RastPort (leider) an einer anderen Stelle. Die Konstante RastPort ist dann mit 50 anzugeben. Da die Variable RastPort nicht zwei Werte gleichzeitig annehmen kann, macht es Sinn, die Kürzel mit anzugeben, also:

Kommt nun eine der Grafikfunktionen von graphics.library, so schreiben wir einfach

und die Parameter können in den Registern übergeben werden, und die Operationen ausgeführt. Ach, das hätten wir ja fast vergessen, welche Funktionen gibt es denn da? Also, die normalen, durchgängigen sind:

SetAPen(RastPort,ColorPen)

Alle Grafikroutinen nutzen eine bestimmte Farbe, wenn sie die Zeichenoperationen durchführen. Mit der Funktion SetAPen() kann der Vordergrundstift verändert werden, und dementsprechend auch die Ausgabe farbiger gestaltet werden. Die Vordergrundfarbe heißt deswegen Vordergrundfarbe, da mit diesem Stift z. B. die Fensterumrahmungen gezeichnet werden. Der Farbstift ist eine Farbnummer, die ähnlich eines Farbkastens zu sehen ist. Der Farbkasten hat z. B. 10 Farben, rot, blau, usw. Der Maler kann jetzt den Pinsel mit einer der Farben färben, was er aber nicht kann, ist die Farbe von Rot nach Grün ändern. Er kann lediglich die Auswahl ändern. Die Anzahl der Farben hängt vom View ab, mehr sagt uns aber der Begriff Srceen. Der Workbench Screen hat oft 4 Farben, die manuell durch das Preferences Programm geändert werden können. Wird auf dem WB-Screen ein Window geöffnet, so stehen auch nur vier Stifte zur Verfügung. Farbe Null ist der Hintergrund.

Obwohl die maximale Anzahl der möglichen Farbregister 32 ist, erlaubt die Funktion größere Werte, denn bei den Grafikmodi EXTRA_HALFBRITE oder HAM sind es ja auch 64 bzw. 4096 Farben. Die Farben werden also nicht immer direkt ins entsprechende Farbregister der Hardware geschrieben, sondern u.U. anders bewertet.

SetBPen(RastPort,ColorPen)

Um beispielsweise zweifarbige Muster zu erzeugen, gibt es neben dem Farbstift A auch noch Farbstift B. Dieser wird entsprechend mit SetBPen() gesetzt.

SetDrMode(RastPort,Mode)

Um den Betriebssystem mitzuteilen, wie die Punkte oder Objekte gezeichnet werden, existieren verschiedene Konstanten, die den Zeichenmodus festlegen:

JAM1 ist normalerweise aktiviert. Ein Linie oder ein Grafikelement wird mit der Stiftnummer APen gezeichnet. Mit JAM2 wird zweifarbig gezeichnet. Bei einem Muster werden die gesetzten Bits mit dem APen und die ungesetzten mit dem BPen umgesetzt. Beispiel: Das Bitfeld 0101010101010101 definiert die Grafikausgabe so, das abwechselnd PenB und PenA genutzt werden. Ist der Mode INVERESID, so werden alle Ausgaben invertiert, daraus folgt: zweimaliges zeichnen löscht die Operation.

Move(RastPort,x,y)(A1,D0,D1)

Die meisten Grafikfunktionen arbeiten mit einem Grafikcursor. Dieser wird mit dem Befehl Move() in einem RastPort an die angegebene Position gesetzt. Um die Routine schneller abarbeiten zu können, prüft das Betriebssystem die Koordinaten nicht auf den richtigen Wertebereich. Daher sollte der Programmierer darauf besonders achten.

Draw(RastPort,x,y)(A1,D0,D1)

Die Funktion Draw() zeichnet von der mit Move() gesetzten Cursor-Position bis zum Punkt x,y eine Linie. Die Koordinaten von x,y werden automatisch zur neuen Grafikcursorposition gemacht. Daher ist es ziemlich einfach, ein Polygon zu zeichnen. Man beginnt mit einer Koordinate, und zeichnet dann immer mit Draw() die nächste Linie.

PolyDraw(RastPort,Anzahl,PolyTable)(A1,D0,A0)

Sollte ein Feld mit Koordinaten zur Verfügung stehen, ist es mühselig, jede der Werte auszulesen, und mit Draw() von Linie zu Linie zu kommen. Daher wurde die Funktion PolyDraw() mit in das Betriebssystem eingebunden, denn mit ihr ist es einfach möglich, ein Feld mit Paaren zeichnen zu lassen. Man stelle sich nur vor, einen Bildschirmrahmen zu zeichnen, immerwieder mit Draw()-Aufrufen. Doch wie wird die Zeichnung erstellt? Wesentlich in die Arbeit eingebunden ist der Wert im D0-Reg., die Anzahl der Punkte, die durch die Funktion verbunden werden sollen. PolyTable ist ein Zeiger auf ein Array der Form X-Koordinate, Y-Koordinate. Die Wertepaare, also die Polynompunkte, liegen als Word vor.

DrawEllipse(RastPort,cx,cy,a,b)(A1,A0-D3)

Mit dieser Funktion erstellt das Betriebssystem auf dem aktuellen RastPort eine Ellipse. Die Mittelpunktkoordinaten sind cx und cy. Die Radien sind durch a und b gegeben. Wer nun meint, man bekäme einen Kreis, wenn a=b ist, der täuscht sich gewaltig. Der Kreis, der einer sein sollte, wird als Ellipse gezeichnet, denn die Form des Pixels ist nicht quadratisch, sondern vielmehr im Verhältnis 4:3 oder sogar noch anders. Bei unterschiedlichen Auflösungen, 320 * 256, 640 * 256, 1280 * 256 müssen also individuelle Werte her, damit ein Kreis ein Kreis wird. Die in C vordefinierte Routine

bringt daher nicht immer was.

Leider ist die Funktion DrawEllipse() nicht sehr schnell. Deshalb sollte man zu eigenen Funktion greifen, wenn es auch Geschwindigkeit ankommen sollte. Zudem ist diese Routine in der Handhabung sehr unflexibel. Wer beispielsweise einen Ellipsenausschnitt für ein Tortendiagramm zeichnen möchte, der kann gleich anfangen selbst zu programmieren.

RectFill(RastPort,x1,y1,x2,y2)

Das Amiga OS bietet zwar keine Funktion zum Zeichnen von Rechtecken (sehen wir von den Bordern einmal ab), wohl aber eine zum Zeichnen eines gefüllten Rechtecks. Die Koordinaten x1,y2 bestimmen die linke obere Ecke, x2,y2 die rechte untere. Es ist wichtig die Tatsache zu Betonen, das x1 < x2 und y1<y2 sein muss, denn andernfalls kommt ein Guru, das geht Ruck Zuck. Die Koordinaten müssen also verglichen, und u.U. vertauscht werden, wenn eine allgemeine Funktion programmiert wird.

Soll ein Rechteck mit zweifarbigem Muster erzeugt werden, so ist der APen und der BPen zu nutzen. Als Modus muss der eben erwähnte JAM2-Mode aktiviert werden. Das Muster muss per Makro übergeben werden, da hierzu keine OS-Funktion zur Verfügung steht. Wie dies gemacht wird, erfährt der Leser in 13.3.1

WritePixel(RastPort,x,y)(A1,D0,D1)

Ein Punkt mit den Koordinaten x,y wird gezeichnet. Es wird ein Ruckgaberegister gesetzt. Ist D0=-1, so waren die Wertepaare nicht im RastPort-Bereich. Interessant ist, das hier nicht der Cursor eingesetzt wird, sondern dass direkt der Punkt auf den Schirm kommt, die Funktion hätte ja auch WritePixel(RastPort) heißen können.

Möchte man einen Punkt löschen, so muss vorher die aktuelle Zeichenfarbe gesichert werden, SetAPen(0) aufgerufen werden, um den Stift auf die Hintergrundfarbe zu legen, dann der Punkt gesetzt (der ja dann gelöscht wird) und letztendlich der Stift wieder restauriert werden.

FarbStift = ReadPixel(RastPort,x,y)(A1,D0,D1)

Um die Farbe eines Punktes heraus zu bekommen muss die WritePixel() Funktion quasi umgekehrt werden. Dazu dient ReadPixel(), der die Farbe des unter x,y, liegenden Punktes herausfindet. Ist der Übergabeparameter negativ, also -1, so konnte keine Farbe ermittelt werden, die die Koordinaten lagen außerhalb des RastPorts, eine Farbe kann nicht übergeben werden. Die Farbe ist nicht in ihre Farb-Komponenten Rot/Grün/Blau aufgeteilt, sondern es wird die Stiftnummer übergeben.

Text(RastPort,Strg,Count)(A1,A0,D0)

Auch in der graphics.libarary findet sich eine Funktion zum Ausgeben von Zeichenketten. Mit Text() kann der String Strg in den RastPort an der mit Move() festgelegten Position geschrieben werden.

Lenght = TextLenght(RastPort,Strg,Count)

Diese Funktion ist eine Zugabe, denn sie hat direkt nichts mit dem Zeichen auf dem RastPort zu tun. Mit ihrer Hilfe wird lediglich die Ausdehnung einer Zeichenkette ermittelt. Damit ist nicht etwa die Anzahl Zeichen gemeint, sondern die Anzahl der Pixel, die der Text in der Horizontalen einnimmt. Die Angabe des RastPort ist notwendig, um den aktuellen Font in die Berechnung einfließen zu lassen. Andernfalls wüsste das OS ja nicht, welcher Zeichensatz verwendet wird, da immer mehrere Zeichensätze im System sein können. Im RastPort allerdings kann immer nur ein Zeichensatz aktuell eingestellt sein.

ClearEOL(RastPort)

Mit dieser Funktion wird ab der aktuellen Grafikcursor-Position eine Zeile gelöscht. Die Zeile kann natürlich, zeichensatzbedingt, verschiedene Höhen haben. Der Zeichensatz, der im RastPort eingetragen ist, gibt dabei die Höhe vor.

Anwendung findet die Funktion z. B. bei Editoren wo eine Zeile gelöscht werden soll.

ClearScreen(RastPort)

Durch die ClearScreen() Funktion wird ab der augenblicklichen Grafikcursor-Position der Bildschirm nach unten hin gelöscht. Dies ist insbesondere bei Editor-Scroll-Funktionen sinnvoll, wenn alle Zeilen eine Position nach oben geschoben werden, und die unterste gelöscht werden muss. Wenn natürlich der gesamte Bildschirm frei gemacht werden soll, ist es möglich, mit Move(0,0) den Stift in der extremsten Position anzusetzen, und dann mit ClearScreen() den gesamten Bildschirm löschen zu lassen. Ein Macro zum Löschen des RastPorts-Schirm hätte folgendes Aussehen:

SetRast(RastPort,FarbStift)

Warum ein aufwendiges Makro benutzen, wenn es auch einfacher geht? Mit der Funktion SetRast() wird ein RastPort mit einer Farbe eingefärbt. Während bei ClearScreen() die aktuelle Farbe benutzt wird, muss sie hier manuell angegeben werden, da die Hintergrundfarbe aber immer Null ist, dürfe das Löschen des Screens kein Problem sein.

Wer sich nun freut, die Routine zum Löschen des Window nutzen zu können, der muss enttäuscht werden, Windows haben zwar einen RastPort, jedoch nicht einen speziellen eigenen, auf einen rechteckigen Bereich beziehenden. Sollte also einmal das Problem kommen, ein Fenster zu löschen, dann kann nicht einer der Befehle (ClearScreen oder SetRast) benutzt werden. Man muss etwas umständlich auf RectFill() zurückgreifen, und ein Rechteck in der Größe des Fensterinhaltes zeichnen.

Nach den gewaltigen Funktionen, ein kleines Beispiel, wie die Routinen genutzt werden können. Die Betonung liegt bei können, ich habe vielfach gefüllte Rechtecke eingesetzt, um nicht vier Linien zeichnen zu müssen, schön ist das auch nicht, aber praktisch.

Das Programm ist eine kleine Grafikanwendung, ein Fenster wird selbstständig aufgebaut. Von Prinzip her macht das AmigaOS es nicht anders. Allerdings kommen hier noch ein paar Sachen hinzu!

Unser Programm öffnet einen Screen, um die Grafikoperationen darüber laufen zu lassen. Es wird über ein Unterprogramm OpenNewWindow ein eigenes Fenster gezeichnet. Auf dem lassen wir einen Kreis zeichnen. Natürlich wird dieser nicht geclippt.

Da ich immer die Strukturen auseinander genommen habe, darf ich den RastPort natürlich nicht auslassen. Die Struktur umfasst $64=100 Bytes.

Der RastPort ist in für grafischen Oberfläche eine wichtige Struktur, die zur Verwaltung der Zeichenebene notwendig ist. Nicht umsonst bekommen unsere beiden Zeichenflächen Window und Screen jeweils ein eigenen RastPort, auf dem die Grafikoperationen durchgeführt werden.

RastPort:

Neu seit 1.2

Offset 0: Layer

Die Layers (eng. für Schicht) sind noch niedrigere Grafikebenen des Systems. Der Amiga benutzt diese Schichten, um etwa Window-Überlappungen und Clippings in Fenstern zu realisieren. Die Layers sind sehr leistungsfähig, und erweisen sich als die Macher der Fenster. Da ihr Zusammenhang jedoch etwas gehobener ist, möchte ich in diesem Buch lediglich das Wort Layer erwähnen, mehr aber auch nicht. (Geplant war ursprünglich ein kleines Scrolldemo für ein Adventure, doch das habe ich aus Platzgründen fallengelassen.)

Offset 4: BitMap

Um an die rohen Grafikbitplanes zu kommen, um evtl. eine schnelle Zeichenfunktion dadurch zu realisieren, ist es notwendig, die BitMap-Struktur zu benutzen, die auch schon einmal bei den Screens angedeutet wurde.

Die BitMapstruktur, mit einer Länge von 40 ($28) Bytes hat folgendes Gerüsst:

Die ersten Felder enthalten die Abmessungen des Displays, und bei den weiteren sind lediglich die Zeiger auf die Planes wichtig. Um beispielsweise ein Screendump zu realisieren müsste man nur die Zeiger auslesen, und durch die Breiten- und Höhenberechnung die Größe errechnen. Ein kleines Pseudoprogramm:

Offset 8: AreaPtrn

Neben dem Füllen von Flächen mit verschiedenen Farben kann die Fläche auch mit einem Muster gefüllt werden. Der AreaPtrn-Eintrag ist ein Zeiger auf das Area-Fill-Muster, das beim füllen verwendet wird.

Offset 12: TmpRas

Ein temporäres RastPort, in dem Objekte aufgenommen werden, die z. B. gefüllt werden.

Die Struct wird durch folgende Zeilen definiert:

Offset 16: AreaInfo

Eine bisher unbesprochene Gruppe der Grafikbefehle sind die Area-Befehle. Im Eintrag AreaInfo sind für die Polynomfunktionen wichtige Informationen abgelegt.

Die AreaInfo-Struktur sieht so aus:

Offset 20: GelsInfo

GELs sind “Graphics ELements“, und erweitern die Grafik des Amigas. Die grafischen Elemente sind die Hardwaresprites, die VSprites (virtuelle Sprites; mehr Sprites, durch Interrupt-Umschaltung) und die BOBs. BOBs wiederum sind größere Sprites, die zwar langsamer und aufwendiger, aber dafür eben größer in den Ausmaßen sind.

Um die GELs zu verwalten, muss eine Struktur angelegt werden, die so aussieht (ich übernehme einfach mal vom INCLUDE-File):

Offset 24: Mask

Mit dieser Variablen lassen sich die Bitplanes, die beschrieben werden können, setzen. Die Schreibmaske ist natürlich als Byte abgelegt, denn ein gesetztes Bit an einer bestimmten Bitposition heißt immer: Zeichnen auf dieser Ebene. Daher ist im Normalfall immer der Wert 256 voreingestellt. Dieser Wert darf einen nicht zu hoch vorkommen, acht Bitplanes sind unter OS 3.0 durchaus möglich, obwohl langsam. Um den VGA-Mode mir 2⁸ = 256 Farben zu bekommen, muss man schon mal zu den Bitplanes greifen, und da ist der Wert 256 angebracht.

Offset 25-27: FgPen, BgPen,AOlPen

In diesen drei Bits sind die Farbregister für die Hintergrund-, Vordergrund- und Umrandungsfarbe gesetzt. Am interessantesten ist die Umrandungsfarben. Wenn sie gesetzt ist, werden die Objekte, die z. B. RectFill() gezeichnet werden, mit Umrandet. Das heißt für ein Rechteck, es werden um ihn vier Linien gezogen.

Offset 28: DrawMode

Die Zeichenmodi hatte ich schon bei SetDrMode() vorgestellt. Sie sind hier noch einmal zusammengestellt.

Voreingestellt ist der Mode JAM2, d.h. es wird mit der Vordergrundfarbe gezeichnet.

Offset 29: AreaPtSz

Wenn das System mit Mustern arbeitet, d. h. AreaPtrn ist mit einem Zeiger auf einem Muster versehen, muss die Höhe dieses Patterns angegeben werden. Die Höhe kann fast unbegrenzt sein, muss sich aber in Zweierpotenz-Schritten bewegen. Möglich sind also Werte von 1, 2, 4, 8, 16, …​ Die Breite darf, wie vermutlich bekannt, nur 16 Pixel breit sein, bevor sie sich automatisch wiederholt. Aus diesem Grunde passen auch gefüllte Muster, obwohl immer an einem anderen Punkt angesetzt, so schon zusammen.

Offset 30: linpatcnt, dummy

Für uns nicht wichtig, da sie intern von Intui benutuzt werden. Dabei soll es ja auch bleiben, oder?

Offset 32: Flags

In den RastPort sind eigene Konstanten eingefügt worden, die da lauten:

Offset 34: LinePtrn

Neben den Flächen lassen sich auf Linien mit einem vordefinierten Muster zeichnen. Wie bei den Flächen ist die Breite auf 16 Punkte begrenzt, was bedeutet, die Anwendung ist leider etwas eingeschränkt, aber was soll s. Meistens, will man eh nur Punkt gesetzt Punkt frei haben, mit der Funktion das Drehen von Objekten zu ermöglichen, wird wohl kaum einer im Kopf haben.

Offset 36, 38: cp_x, cp_y

In den beiden Feldern sind die wichtigen Grafikcursor-Positionen gespeichert, die mit dem Move()-Befehl gesetzt werden, und z. B. von der DrawLine()-Funktion genutzt wird.

Offset 40: minterms[8]

Auch diese acht Byte-Einträge sind für uns unwichtig, denn sie sind Intuition intern.

Offset 48, 50: PenWidth, PenHeight

In den beiden Words ist die Cursorbreite und Cursorhöhe gespeichert.

Offset 52: Font

Dieser Zeiger ist eine Referenz auf den gerade aktuellen Zeichensatz, der in dem RastPort aktiv ist. Wie dieser umgestellt werden kann werden wir im nächsten Kapitel erfahren.

Offset 56: AlgoStyle

Neben den grundsätzlichen schrifttypischen Erscheinungsbild, kann der Amiga die Zeichen in einigen verschiedenen Varianten ausgeben, die durch die Konstanten:

angegeben werden. Der Strukturoffset heißt nicht umsonst AlgoStyle, der Zeichensatz ist nicht neu, nur durch einen Algorithmus verändert worden. Im nächsten Kapitel werden wir mehr über Zeichensätze erfahren. Wir werden auch die Anzahl der künstlichen Schrifttypen erhöhen, indem wir einen Text outlinen.

Offset 57: TxFlags

In diesem Byte finden wir eine textspezifische Konstante,

Sie wird ebenfalls intern von Intuition gebraucht.

Offset 58: TxHeight

Um beim Vorschub in die nächste Zeile die Position errechnen zu können wird die Texthöhe benötigt. Diese wird in der Struktur an Offset 58 abgelegt. Der Zeichensatz, dessen Höhe eingetragen wird, ist immer der aktuelle, der auch in Font gesicherte.

Offset 60: TxWidth

In TxWidth findet der Anwender die durchschnittliche Breite jedes Zeichens. Verwendet werden meist Zeichensätze mit konstanten Textbreite, wie 8 Pixel. Da aber der Trend hin zu proportionalen Zeichensätzen geht, die Zeichen haben verschiedene Breiten, i ist schmaler als ein m, kann in diesem Eintrag nur ein Durchschnittswert eingetragen werden.

Offset 62: TxBaseline

Jeder Text wird mit verschiedenen Größen auftauchen. Unter anderem ist für die Ausgabe die Höhe des Textzeichens und die Höhe des Textzeichens ohne die Unterlänge wichtig. Buchstaben mit Unterlängen sind z. b. "g", "j", "y". Die Texthöhe ohne Unterzeichen des "g" ist also die Höhe eines "o", obwohl die reine Texthöhe natürlich unterschiedlich ist. Wofür braucht man das? Nun, denken wir uns eine Linie, auf der ein Text stehen soll. Man zieht nun von der gewünschten Position (z. B. 30) TxBaseline (z. B. 6) ab, und hat dann die Koordinate (30 - 6 = 24), an der die Zeichen ausgegeben werden müssen, damit sie auf der Linie sitzen.

Offset 64: TxSpacing

Wir kennen aus dem Schreibmaschinenunterricht bestimmt das Sperren von Texten zur Hervorhebung. OK, damals konnte eine Schreibmaschine noch nicht fett drucken, da musste man Besonderheiten eben so hervorheben. Mit der Variblen TxSpacing lässt sich auf bei der Amiga Textausgabe der Abstand zwischen den Buchstaben ändern. Der Wert ist normalerweise auf Null gesetzt, was bedeutet, es werden Null Leerpixel zwischen den Lettern gesetzt. TxSpacing = 8 würde acht freie Pixel von Buchstabe zu Buchstabe lassen, was unser normal gesperrtes wäre.

Offset 66: RP_User

Um den Benutzer wieder in die Struktur eingreifen zu lassen, ist ein freies Feld mit einem Long beschreibbar.

Offset 70-92: longreserved[8], wordreserved[14], reserved[8]

Soll uns nicht interessieren.

Nachdem nun ein kleines Grafikdemo die wichtigsten Funktionen klärte, und auch die RastPort Struktur ausreichend beleuchtet wurde, wir ein weiteres Programm die Grafikzeichenbefehle abrunden. Ich stelle folgend ein kleines Zeichenprogramm vor, das die wichtigsten Funktionen wie Linie, Kreis zeichnen und Punkt setzen beherrscht. Der besondere Clou ist, dass der Programm eine Protokolldatei erstellt, über alles, was gezeichnet wurde. Das Zeichnen der Punkt-Linien ist aber noch fehlerhaft, und könnte verbessert werden.

Mit dem View-Port wird fast die unterste Ebene des Systems erreicht. Von hier an geht es fast immer an die Hardware. Das erklärt aber noch nicht, was ein ViewPort ist, bisher haben wir in lediglich charakterisiert. Versuchen wir ihn im folgenden etwas genauer zu präzisieren. Der ganze Bildschirm wird als sein Gesamtes Display genannt. Ein Display besteht aus mehreren Viewports. Jeder Viewport kann seine eigene Grafikauflösung, Farben und Bitplanes nutzen. Wir schöpfen verdacht, das kennen wir doch schon! Na klar, von den Screens. Ein Screen kann auch seine Auflösungen und Farben haben. Wo ist also der Unterschied? Das ist einfach, ein Screen ist nichts anderes als ein ViewPort mit etwas drum herum. Jeder Screen ist ein ViewPort.

Obwohl ViewPort ziemlich flexibel sind, können wir einiges nicht mit ihnen machen, etwas, was von den Screens schon bekannt sein sollte.

ViewPorts

Steigen wir gleich in die Aufgaben des ViewPort ein. Wir wollen Farben verändern. Da der View-Port die Struktur ist, die für Farbänderungen zuständig ist, müssen wir sie verwenden. Der Screen, dessen Farbe wir mal ändern wollen, hat daher für uns Programmierer den RastPort und den ViewPort für uns als benutzbare Zeiger hinterlegt.

ViewPort, Größe 40 ($28) Bytes:

Offset 0: Next

Das der gesamte Display aus oft aus mehreren Viewports besteht, hier die Verbindung zu den anderen.

Offset 4: ColorMap

Um jeden ViewPort seine eigenen Farben zu erlauben, muss eine Datenstruktur definiert werden. Diese ColorMap gibt die Farben für den Bildschirmausschnitt an.

Ich zitiere auch hier aus den INCLUDE-Dateien:

Offset 24 und 26: DWidth, DHeight

Hier findet der Suchende Breite und Höhe des ViewPorts.

Offset 32: Modes

In Modes wird der aktuelle Ausgabestand vermerkt. Folgende Konstanten sind vertreten. Wir haben sie aber schon kennengelernt, als wir nämlich einen Screen öffneten.

Offset 36: RasInfo

Eine Struktur folgenden Formates:

Um Farben zu verändern kann der RastPort nicht mehr helfen, der View-Port muss her. Denn speziell bei Farbregisterbeschreibungen ist die Copper-Liste im Spiel, und die wird durch den View verwaltet.

SetRGB4(ViewPort,Reg,r,g,b)(A0,D0-D3)

Mit dieser Funktion kann innerhalb eines Views ein Farbregister verändert werden. Der Farbwert ist in die Komponenten Rot, Grün und Blau aufgespalten. Jeder der Komponenten kann Werte von 0 bis 15 annehmen, die Gesamtzahl der Farben ergibt sich damit zu 16 * 16 * 16 = 4096.

Vorteil der Funktion ist, dass die Farbwerte direkt in die ColorMap übertragen werden, und dies bedeutet wiederum, dass die mitberechnete Copper-Liste sofort die Farbe auf den Bildschirm bringt.

Farbe = GetRGB4(ColorMap,FarbReg)(A0,D0)

In einigen Fällen ist es notwendig die Farben der Color-List auszulesen. Mit GetRGB4() steht dem Benutzer so eine Funktion zur Verfügung. Die Farbwerte werden z. B. in einem Farbrequster verlangt, man muss ja wissen, wie die Grundfarben sind, oder in einer Bilder-Sicherungs-Routine, die die Farbinformationen auch auf das Medium schreibt. Wo die GetRGB4()-Funktion noch drei Register für den Farbwert benötigte, ist hier die Farbe in einem Register zusammengefasst, so wie sich auch von der Hardware aufgenommen wird. Wir haben im Kapitel über Preferences schon einmal darüber gesprochen.

Wir von der Funktion eine -1 an die aufrufende Einheit zurückgegeben, so wurde versucht, von einem Farbregister auszulesen, was keine gültige Farbe enthielt. Es ist also nicht möglich auf einem 3 Plane-Screen mit 8 Farben den Farbwert von Register 18 auszulesen.

Eine Information, die verwirren könnte: -1 assoziiert man mit allen gesetzten Bit, der Farbwert Weiß ist aber auch durch alle gesetzten Bits definiert. Man darf natürlich nicht annehmen, das weiß eine ungültige Farbe ist, denn -1 sind 32 gesetzte Bits, die Farbe Weiß aber nur die untersten 12!

LoadRGB4(ViewPort,Palette,Anzahl)

Mit den beiden oberen Funktionen konnten lediglich einzelne Farbregister verändert werden. Dies verkompliziert jedoch bei großen Palettenänderungen das Programm, sinnvoll wäre nun eine Routine, die mehrere Einträge gleichzeitig ändert. Mit der Funktion LoadRGB4() wird aus einer Palette die Farbeinträge in die ColorMap des ViewPort geschrieben. Die Farbpalette ist eine Tabelle, die aus aneinandergehängten Words besteht, die das oben genannte 4-Bit-Pro-Farben Format haben. Die Farbeinträge werden bei Null beginnend geändert. Gezielt von einem Startregister die Anzahl abzulaufen ist nicht möglich, und in vielen Fällen auch nicht sinnvoll.

Um sie auch noch sichtbar zu machen, muss ein weiterer Schritt ausgeführt werden.

Mit dem Befehl LoadView(ViewPort) wird die erstellte Copper-Liste ausgeführt, und dadurch der View mit einer neuen Farbe dargestellt.

Wie jede Library gibt auch die Gfx-Lib einiges an Informationen in der Gfx-Base her. Ich habe nur ein paar herausgegriffen, und zwar die, die in den INCLUDES beschrieben sind.

Neu hinzugekommen ab 2.0:

Offset 34: ActiView

Ein Zeiger auf den aktuellen View.

Offset 38: copinit

Ein Zeiger auf die startende Copper-Liste.

Offset 42: cia

Für den 6526 Resource-Gebrauch.

Offset 46: blitter

Für den Blitter resource-Gebrauch.

Offset 50 und 54: LOFlist, SHFlist

Zeiger auf Copper-Liste, die gerade läuft.

Offset 58: blthd

Ein Zeiger auf die Blitternode.

Offset 206: DisplayFlags

Folgenden DisplayFlags werden angeboten:

Immer denselben Zeichensatz vor Augen zu haben ist auf die Dauer ziemlich anödend. Nicht umsonst wurde der alte Topaz-Zeichensatz, der bis 1.3 den Rechnern im ROM mitgegeben wurde, durch einen neuen ersetzt, der viel ansprechender ist. Wer kein 2.0 hat, muss aber nicht frustriert sein, denn es gibt ja immer noch den Befehl SetFont im c/-Verzeichnis der Originaldiskette. Damit kann ein Font als CLI Font aktiviert werden. Als ich noch kein 2.0 hatte, griff ich auf den Zeichensatz pearl.font zurück. Im Nachhinein muss ich sagen, dass er dem neuen Topaz recht nahe steht.

Neuere Programme überzeugen durch gekonnte Zeichensätze, die nicht nur zur Lesbarkeit neu konstruiert werden. Auch viele Sonderzeichen können in das System eingebunden, und benutzt werden. Oft wird in den Fenstern und Menüleisten neue Zeichensätze neue Schriftzeichen angeboten, die sehr gut aussehen. Unter 2.0 können die Zeichensätze auch gesetzt werden.

Das OS unterscheidet zwischen 2 Zeichensätzen. Die aus dem ROM und die nicht aus dem ROM kommen, also externen Ursprungs sind. Im ROM sind zwei Zeichensätze gespeichert, Topaz 8 und Topaz 9 (9 ist größer als acht), die externen müssen sich im FONTS Verzeichnis einer Diskette befinden.

Um nun die Zeichensätze ansprechen zu können bedarf es eigentlich keinerlei Aufwand. Lediglich eine kleine Struktur ist zu füllen. Sie heißt TextAttr und hat eine Länge von 8 Bytes.

Hier sind die Wünsche an den Zeichensatz gestellt.

Ein Beispiel, wie so eine Struktur aussehen kann:

Die Verwaltung der internen und externen Fonts geschieht über dieselbe Struktur.

Nachdem TxtAttr geladen wurde, kann ein Zeichensatz angesprochen werden. Dazu werden zwei Funktionen verwendet. Ist der Zeichensatz intern, so arbeitet man mit der OpenFont()-Funktion aus der graphics.library, andernfalls wird eine neue bisher unbekannte Library eingeschaltet, die diskfont.library. Sie ist extern, und wird daher beim Öffnen von der Diskette geladen. Sie enthält nur vier Funktionen. Die wichtigste davon ist OpenDiskFont(), um externen Zeichensätze zu laden. OpenDiskFont() wird lediglich ein Zeiger auf die TextAttr-Struktur übergeben, und der Zeichensatz wird geladen.

Zurückgegeben wird eine andere Struktur, die TextFont heißt. Für weitere Arbeiten (OpenFont(), AddFond()) ist sie notwendig.

Eine genaue Beleuchtung spare ich mir.

Die Größe der Struktur beträgt 52 ($34) Bytes.

Um einen Font zu laden, und ihn in das System einzubinden, muss dieser noch aktiviert werden. Dies geschieht mit SetFont().

Auch ein internen ROM Zeichensatz muss mit SetFont() aktiviert werden. Ein geladener externer Zeichensatz, und ein interner sind also dann von der Bearbeitung her gleich.

Ob ein Font aus dem RAM oder dem ROM kommt muss mit AvailFonts() erfahren werden. Die Funktion wird am Ende des Kapitels erläutert.

Das nachfolgende Programm lädt einen Zeichensatz, und gibt einen kleinen Test aus. Die Vorgehensweise ist folgende:

Der Zeichensatz ist Helvetica. Die Größe von 20 Punkt wird der ladenden Prozedur beigegeben.

Um einen Text zu schattieren muss einfach mit der Farbe schwarz — sie muss aber dann vorhanden sein — oder einer dunkleren Farbe etwas unter dem Originaltext der dunklere erscheinen. Wir setzen daher erst den Text ersten um einen Pixel nach oben und unten versetzt, und dann den Originaltext.

Das alte Unterprogramm PrintText muss gegen das neue ausgetauscht werden.

Um einen Text einen Outline zu geben ist in folgenden Schritten vorzugehen:

Auch hier muss das alte Unterprogramm PrintText muss gegen das neue ausgetauscht werden.

Die req.library ist eine re-entrant library, die von Colin Fox und Bruce Dawson programmiert wurde. Sie soll dem Programmierer alle möglichen Dialoge (Requester) bereitstellen: Color-Requester, File-Requester, Message-Display-Requester und andere Funktionen zur Gadget-Erstellung.

Wir wollen nur eine kleine Funktion der riesigen Bibliothek nutzen. Es sei dem Leser eine weitere Nutzung überlassen, die nicht versäumt werden sollte.

Wir wollen einen File-Requester erstellen, der dem Benutzer eine Auswahl einer Datei erlaubt. Dazu benutzen wir die Funktion FileRequester() aus der req.library, die selbstredend vorher geöffnet werden muss. Zu übergeben ist der Funktion ein Zeiger auf die FileRequesterStructure im A0-Register. Die Einträge können fast überall null sein. Der Rückgabeparameter kann TRUE oder FALSE sein. Der Zeiger auf den gewählten Dateinamen wird nicht übergeben, er muss aus der Struktur ausgelesen werden.

Wichtig ist das die Versionsnummer stimmt. Bei Darstellen des Dateiauswahldialogs ist die Versionsnummer der Library anzugeben.

Noch zwei kleine weitere Konstanten sind in der Headerdatei zu finden.

Nun zur FileRequester-Struktur, der der Funktion zum Öffnen übergeben werden muss:

Sollten nicht unbedingt geändert werden

Folgendes darf nicht benutzt werden und ist privat:

Nachfolgend sind die Bits der Flags aufgeführt. Es sind nur die Bits, noch nicht die Werte!

Benutzer des 2.0 Betriebssystems können auf die requester.library verzichten (müssen es aber natürlich nicht). Sie können einen File-Requester der externen asl.library nutzen.

Wie so ein Programm aussieht, können wir leicht am nachfolgenden Demo demonstrieren.

Nach dem Öffnen werden einige Felder gefüllt, die aber nicht vorgestellt werden.

Der File-Requester ist sowieso nicht so toll, da kann man lieber auf PD-Requester zurückgreifen, die sind zurzeit noch wesentlich besser und schneller. Kein Wunder, dass der Asl-Requester oft gepatcht wird. Ich will daher auf den Asl-Requeser nicht weiter eingehen.

Die Hardware des Amigas ist in mehrere Komponenten strukturiert. Da wären zunächst einmal die CPU, die RAM-Bausteine, der Floppy-Controller, die Grafikbausteine, der Taktgeber, der Musi-Mann, und noch so einige kleine Sachen. CPU Programmierung dürfte klar sein, RAM wird immer angesprochen. Bleiben noch die Bauteile, die die Datenkommunikation und die audio-visuelle Darstellung übernehmen.

In bestimmten Speicherzellen, die wir gleich etwas näher kennenlernen wollen, finden wir Werte, die ausgelesen werden können. Dies hört sich zwar selbstverständlich an, ist es aber noch lange nicht. Denn, nicht jeder Speicherbereich kann geschrieben und gelesen werden.

Eine Speicherzelle, mit der Adresse $BFE001 haben wir schon kennengelernt. Der Inhalt ist der Zustand einer gedrückten Maustaste, ob gedrückt, oder nicht, 0 oder 1 ist der Inhalt. Die Hardware regelt das selber, es ist also nicht so, das irgend ein Interrupt da arbeitet, und die Werte beschreibt.

Zufallswerte selbstgemacht

Zufallswerte mathematisch

Die erste Routine nutzt zur Ermittlung einer Zufallszahl eine Adresse, an der sich die Rasterzeile befindet. Der Wert wird noch ein bisschen verändert, und wir erhalten einen Zufallswert.

Leider ist dieser Weg nicht besonders schön, es gibt noch eine weitere Variante, Zufallszahlen quasi zu errechnen. Man geht von einem Startwert aus, verändert diesen, und nimmt ihn wieder als neuen Startwert. Eine Routine, die auch häufig in C oder anderen Programmiersprachen zu finden ist.

Alle Koprozessoren sind über Speicherzellen zu „erreichen“. Diese Speicherzellen sollte man schon kennen, daher eine belehrende Tabelle.

Der Copper ist einer der Koprozessoren, die die Bildschirmdarstellung übernehmen.

Der Mikroprozessor, der im Amiga 500 (500+) aktiv (mit)arbeitet, ist der MC68000 von der Herstellerfirma Motorola. Der Name, oder besser die Zahl, kommt daher, dass er ca. 68000 Transistoren enthält. Diese sind auf einer Fläche von 6,2 mal 7,1 mm untergebracht. Der Prozessor gehört schon der vierten Generation an. Zur damaligem Zeit machte Intel, heute in allen PCs als Hauptprozessor angestellt, das Rennen (Diese Prozessoren sind eigentlich noch aus der 3. Generation). Motorola, und z. B. Zilog mit dem Z80, versuchten in das lukrative Geschäft einzusteigen. Dies versuchten sie mit Prozessoren höherer Leistungsfähigkeit, die z. B. mehr Befehle hatten, schnellere Ausführbarkeit aufwiesen und mehr Speicher adressieren (ansprechen) konnten. Der Trend ging in den späteren Jahren einfach nach Prozessoren, die idealer für höhere Programmiersprachen, insbesondere Compiler, waren. Eine strukturierte Programmierung und eine Überschaubarkeit sollte auch auf der untersten Ebene noch gewährleistet sein.

Motorola wollte einen Super-Prozessor dieser Art herausbringen. Im Jahre 1977 wurde das neue Projekt gestartet. Mit dem Grundgerüst vom MC6800 gelang es den Spezialisten Tom Gunter und Co. XC 68000 (gelegentlich auch M68000 genannt) im Jahre 1979 auf den Markt zu bringen. Doch für den großen Markt war es zu spät, denn Intel hatte die Macht im Chip-Geschäft, und dass dies immer noch so ist, zeigt das heutige Bild. (Der damalige Intel-Prozessor konnte jedoch nur einen kleinen Speicherbereich ansprechen. Er entsprach 64 KB. (Hätte gut in den C-64 reingepasst). Doch heute verfügen die Rechner über größere Mengen Speicher (CAD Anlagen und Grafik Studios zur Bildnachbearbeitung benötigen Giga-Speicher), so dass Intel, die ja Prozessoren herstellen wollten die zu den alten kompatibel sein sollten heute rummurkst ohne Ende, da ja der erste Intel-Prozessor nur 64 KB ansprechen konnte. Man trickste das bei den 640 KB PC-Rechnern so hin, dass man Bänke einführte. Diese Bänke waren je 64 KB groß und daraus folgte, dass immer zwischen den Bänken rumgeschaltet werden musste, um in den Genuss des ganzen Speichers zu kommen. Wer einen C-128 hat, dem wird das vielleicht bekannt vorkommen, denn auch dort ist der Speicher in Bänke eingeteilt. Dieses Umschalten nennt man Bank switching, und der Hardwareteil, der dies übernimmt, nennt man Bank-Select-Logic. (Für Insider: Auch der C-64 hat dies im kleinen Format, denn man bedenke nur das nutzbare RAM, welches unter dem ROM noch zu verwenden ist! (Ist nur ein Vergleich!!) Bei den PCs prägt ein 64K-Bänkesystem ein Assemblerprogramm, und über eine Berechnung mit Hilfe von Segmenten und Offsets kommt man zu der ersehnten Adresse. (Doch zum Trost sei gesagt, dass die neuen Intel-Prozessoren (ab den 80286) auch diese Bänke weglassen können und einen durchgehenden Speicher haben!)

In den Anfangszeiten, in der die Firma Motorola Mikroprozessoren herstellte, sind integrierte Schaltungen wie der 6800, 6802, 6803, 6809 entstanden. Zu dem schon auf dem Markt befindlichen MC68000 brachte Motorola noch den MC68008 heraus. Er hat den gleichen Befehlssatz wie der MC68000 unterscheidet er sich von ihm in einem wesentlichen Punkt. Er spricht nur einen kleineren Speicherbereich an, und da er mit 48 Pins deutlich kleiner ist als der 68000 mit 64 Pins, eignet er sich besonders gut für kleine Einplatinenrechner. Der 68008/10 (die Zahl hinter dem Querstrich gibt die maximale Taktgeschwindigkeit an (die die Firma für angemessen hält)) kostet etwa 25 DM.

Weiterentwicklungen

Eine direkte Weiterentwicklung des 68000, obwohl doch schnell fertig, ist der MC68010. Er ist in der Lage die Trap-Vektoren-Tabelle (Exception-Vektortabelle) zu verschieben. Zudem hat er die prima Einrichtung, den Loop Modus, der eine Weiterentwicklung des Befehl-Prefetches (Befehl aus dem Speicher in den Prozessor holen) ist. Durch diese Technik kann meist der letzte Befehl und die Registerwahl gespeichert werden. Der Prozessor verfügt intern über ein Zwei-Wort-Prefetch und ein Ein-Wort-Befehls-Register. Ist der Prozessor einmal in den Loop Modus gelangt (durch die spezielle Schleifenkonstruktion DBcc), benötigen die Befehle (33 sind möglich) nicht erneut aus dem Speicher geholt zu werden, sondern stehen in den Prefetch-Registern zur Verfügung. Der Prozessor benötigt also nur noch die Zeit für die Ausführung der Befehle, führt jedoch keinen Befehls-Lade-Zyklus (Fetch) durch. Dies kann bei Verschiebungen und Suchaktionen sehr sinnvoll sein. Der 68010/8 kostet 28 DM und ist eigentlich gut einzusetzen. (Siehe bei „Was ist nutzbar“)

Ein weiterer Prozessor der 680x0 Familie ist der 68012, der aber eine unwichtige Rolle spielt. (Wenn er überhaupt noch eingesetzt wird). Er erweitert den 68010 insofern, als er mehr Speicher adressieren kann.

Wenn wir die Amigazeitungen aufschlagen, werden uns immer wieder Werbungen ins Auge fallen. Slogans wie „Noch billiger“ und „Noch besser“ sowie „Aktueller Update“ prägen dieses Bild. Fast unscheinbar sind die Beschleunigerkarten (klar, bei dem Preis). Sie reichen von 68000 auf 16 MHz getaktet bis 68020-68040er Karten, die bis zu 50 MHz getaktet werden können. Einen Computer mit 68000, der auf eine höhere Taktgeschwindigkeit läuft, kann sich jeder selbst anfertigen, wenn er den eingebauten 8 MHz Chip (MC68000P8) (der für eine Zugriffszeit etwa 500 ns benötigt) gegen einen 16 MHz Chip (MC68000P16) austauscht und ihn mit einem eigenen Oszillator (Taktgeber) (der ca. 5 DM kostet) am Taktbein 20 des Prozessors versieht. Ich bitte aber um Vorsicht, denn die Beine (Pins) könnten leicht abbrechen, denn eigentlich benötigt man zum Herausheben eines so großen Chips eine Spezialzange. Die Utensilien, wie Prozessor, Oszillator und Zange, sind Im Elektronikfachhandel zu bekommen. Der normale MC68000 ist standardmäßig auf 8 MHz getaktet und kostet 12 DM. Typen, die bei höheren Frequenzen arbeiten sind selbstverständlich teurer. So kostet der 68000/10 14,50 DM, der 68000/12 14,50 DM, der 68000/14 17 DM und der 68000/16 47 DM.

Die Erweiterungskarten bieten dem Amiga-User höhere Taktgeschwindigkeit an, und die Prozessoren haben ab dem 30er einen Mathecoprozessor, der schnellere Fließkommazahlenoperationen erlaubt. Zudem ist durch Cachespeicher (Speicher im Prozessor) (beim 40er auch zwei mit je 4 KB) der Speicherzugriff um 80–90 % auf diesen verlagert, da nicht immer alles über den Datenbus laufen muss. Überhaupt ist der Speicher viel zu langsam und die heutigen Supermodern-Prozessoren sind schon schneller als der Zugriff auf den RAM-Speicher. Wenn man durch Erweiterungskarten den Cache-Speicher noch erhöht, so was gibt es schon für den 3000er lassen sich umgerechnet 75 MHz erreichen. Ein Computer müsste also auf 75 MHz getaktet werden, um diese Leistung ohne Cache zu erbringen. Cache bringt Vorteile. Doch auch durch einen Prozessor wie der 68010, den jeder in seinem Computer einsetzen kann, kann man die Geschwindigkeit erhöhen. Denn mit diesem Prozessor lassen sich Schleifendurchläufe schneller erledigen. Somit wird die Prozessorleistung im Durchschnitt um 20 % erhöht. Leider hat dieser Prozessor einen kleinen Nachteil in den TRAP-Routinen. Doch gibt es da ein PD-Programm auf der Amiga-Lib-Disk (Fisch-Disk) Nr 18. namens DeciGEL (Zitat des Autors: „Relief from MC68010 pains on the Amiga“), die diesem Fehler entgegenwirken. Doch ein PC- oder Atari-Emulator habe ich bis jetzt auf diesem Prozessor noch nicht zum Laufen gebracht. Und wer wie der A500+ oder 3000 ein 2.0 Betriebssystem hat, bei dem funktioniert es auch mit Normalprozessor 68000 nicht.

Was die Erweiterungskarten nicht können, ist jedoch die Geschwindigkeit der Coprozessoren (Commodore gab ihnen Namen wie Copper (Co-Prozessor), Blitter (Block-Transfer), Paula oder Denise) (auch dazu später mehr) heraufsetzen. Selbst bei dem A3000 bleibt sie bei 7 MHz, die Taktgeschwindigkeit eines normalen Amigas. Etwas schwach. Doch lässt sich im Laufe des Jahres 1992 auf einen Amiga++ mit 14 Megaherz Takt- und Coprozessor-Frequenz warten. Die Geschwindigkeit ist u. a. ein Grund, warum die Demos auf dem 3000 fast alle nicht mehr laufen. Es liegt einfach daran, dass immer angenommen wird, die Coprozessoren seien schneller als der Prozessor, und wenn eine super 40er-Turbokarte ihren Dienst in einem voll aufgerüsteten Amiga tut, ist das nicht mehr der Fall, denn durch die Unabhängigkeit der vielen Prozessoren (der arme PC) ist der Prozessor schon fertig, wenn der Blitter gerade mal anfängt seine Blöcke zu verschieben. Das Programm kommt aus dem Takt, und verabschiedet sich mit einem roten Ticket zum Guru nach Indien. Das ist in den meisten Fällen natürlich sehr ärgerlich, denn jeder sollte sich den Reiz der Demos nicht entziehen, denn nur sie zeigen wirklich, was ein Computer so alles draufhat. Am PC wäre dies schon gar nicht möglich, denn die Hardware ist zu verschieden. Es gibt zwar nun VGA als Grafik-Standart und Soundblaster als Microsoft-Window-Musikstandart, doch sind immer noch andere Karten im Einsatzbereich, auf denen nun wiederum laufen einige Tricks nicht. Zudem sind die Taktgeschwindigkeiten zu verschieden, eine Abstimmung mit der Hardware ist also nicht zu erzielen. Der C-64 und Amiga sind Idealcomputer, da sie alle die gleichen Hardware-Voraussetzungen erfüllen.

Schon in den ersten Kapiteln war zu erfahren, dass ein Befehl aus mindestens 16 Bit, d. h. einem Word besteht. Mit 16 Bit lässt sich schon eine Menge anfangen, so sind theoretisch 2¹⁶ = 65636 Befehleskombinationen denkbar. Es haben jedoch einige Bits an bestimmten Positionen vordefinierte Bedeutungen, sodass die Anzahl der Bits, die Befehle identifizieren, gewaltig schrumpft. Bei Einzelbefehlen ist dies anders. Jede Mnemonik hat eine eigene Kennung. Die folgende Tabelle zeigt Befehlswörter mit ihren Bitkombinationen:

Sehen wir von Mnemonik ILLEGAL ab, tritt deutlich hervor, dass die übrigen mit der Bitkombination %010011100111…​. beginnen. Im Folgenden wollen wir die Bitkombination auch Opcode nennen.

Besprochen sind die einfachsten Befehle, und ein Assembler wird keine Schwierigkeit haben, diese in entsprechende Opcodes (so nennen sich die Bitbelegungen) umzusetzen.

Aber wie kommt es dazu, dass der Assembler die Befehle erkennt, und in Bit umgesetzt? Ich möchte verschiedene Möglichkeiten zur Befehlserkennung diskutieren.

Vor dem Suchen muss der Compiler erst einmal zu einem Schlüsselwort kommen. Wichtig ist, dass die Schlüsselwort-Erkennungsroutine Returns, Leerzeichen und Tabulatoren überspringt, denn sie sind Trennzeichen und gehören nicht zum Befehl. Oft kommen im Programmquelltext Bemerkungen hinzu, die ebenfalls übersprungen werden müssen. Erschwerend wirkt, dass eine Labeladresse, eine Variablenzuweisung oder Variablendeklaration (Konstante) auch als solche erkannt werden muss, und nicht fälschlicherweise als Schlüsselwort.

Ein Beispiel aus einem willkürlichen Programmtext:

Hier müssen die ersten vier Zeilen und der Labelname Klaus sowie das Leerzeichen übersprungen werden, um zum NOP zu kommen. Nachdem alles unnütze (für die Befehlserkennung) beiseitegelassen wurde, kann der Assembler den Befehl in einen Puffer kopieren. Kopiert wird ab dem ersten Zeichen und die Routine abgebrochen, wenn ein Trennzeichens (Delimiter) gefunden wurde. Nach dem Abschluss mit einem Nullbyte ist der Befehl zur Weiterbearbeitung fertig. Der Puffer hat etwa folgendes Format:

Ist nach erfolgreicher Separation vom Programmtext ein Befehl „frei“ (isoliert), kann die Erkennung gestartet werden, ob der Befehl existiert, und welche Maßnahmen entsprechend ergriffen werden müssen.

Die Erkennung besteht dabei aus dem Suchen der Befehlswörter aus einer Tabelle und springen zum passenden Unterprogramm, wo weiters erfolgt. Zum Suchen gibt es viele Möglichkeiten. Kurz ansprechen werde ich folgende Techniken:

Die Erste Suchmöglichkeit wäre:

Der Assembler durchsucht sequentiell eine Tabelle, in der alle Befehlswörter tabellarisch mit einer Sprungadresse verbunden sind, und kann dann das Unterprogramm anspringen, welches die Bitkennungen in den Speicherbereich schreibt, in dem das Programm hineinassembliert werden soll.

Eine Beispieltabelle:

Der Nachteil dieses Suchens liegt auf der Hand. Um zum letzten Befehl zu kommen, müssen wir alle 55 restlichen Befehle um mindestens einen Buchstaben verglichen haben. Aufgrund dessen kann man nun oft gebrauchte Befehle vorne einordnen, sodass ein Vergleich möglichst wenig ausgeführt wird. Statistiken besagen deutlich, dass der MOVE-Befehl am häufigsten auftaucht. Logischerweise ordnen wir ihn in der Tabelle so an, dass der Puffer direkt mit ihm verglichen wird. Was nach dem MOVE kommt könnte etwa in der Häufigkeit ein ADD sein. Also ordnen wir ein ADD so an, der er direkt nach dem Vergleich mit MOVE kommt. Die Suche kann also immens beschleunigt werden, indem die Befehle geschickt angeordnet werden.

Leider ist dieses Suchen, obwohl der Algorithmus einfach ist, langsam, und so suchen wir uns eine andere Technik aus, mit der wir schneller zum Ziel kommen. Denn einleuchtend ist, dass die Anzahl der Befehle, die oft gebraucht werden, schnell erschöpft ist, und Befehle auftauchen, die gebraucht werden, aber alle sporadisch, und nicht unbedingt häufig. So kann es wegen der Befehlsvielfalt leicht vorkommen, das ein Vergleich mit LSL erst an 20. Stelle auftaucht, denn nach einem subjektiven Befinden sind andere Befehle häufiger, sodass z. B. MULU an 19. Stelle gestellt wird.

Auch Compiler haben Einfluss auf die Befehlswahl, denn sie sind nie optimaler als Assembler-Programmierer, und der wird versuchen, Befehlsmöglichkeiten und Adressierungsarten auszunutzen. Im Gegensatz dazu stehen Compiler, die oft MOVEen, PEAen und EXTen. Jeder kann zugeben, das der PEA-Befehl von Assemblanern nicht (oder nur ganz wenig) (vielleicht von Atarianern) gebraucht wird. Ebenso eine Vorzeichenerweiterung mit EXT (sehen wir von den mathematischen Operationen ab), denn als Programmierer haben wir immer im Kopf, ob sich nun ein Word, Long oder Byte im Register befindet. Compiler dagegen nutzen PEAs immer, wenn Adressen auf den Stack sollen, und das passiert häufig, man denke nur, wie oft printf, scanf oder ähnliches aufgerufen wird. Auch EXTed werden häufig genötigt, denn unser Compiler hat so seine Schwierigkeiten mit dem Merken von Wertbereichen.

Sollte das sequentielle Suchen bevorzugt werden, so müssen im Fall, dass schnelle Ergebnisse gewünscht werden, auch verschiedene Häufigkeitstabellen angelegt werden, ganz danach, was für einen „Befehlsvorrat“ der Programmier oder Compiler besitzt. Wir merken schon, viel zu langsam, und viel zu aufwändig.

Über schnellere Suchroutinen kann man sich allerdings auch wieder streiten. Doch besprechen wir erst einmal eine neue Möglichkeit bevor wie tadeln.

Binäres Suchen:

Jeder hat bestimmt schon etwas vom binären Suchen behört. Diese Technik soll folgend diskutiert werden.

Wir beginnen in der Mitte mit dem Suchen des Schlüsselwortes, und beim Nicht finden halbieren und suchen wir solange weiter, bis das Wort gefunden wurde. Bei 56 Befehlen benötigten wir im Ernstfall sechs Wort-Vergleiche. Dies ist wenig und dementsprechend schnell. Die Zwischenstopps, die erreicht werden, um den ersten Befehl in der ASC-Tabelle zu finden, sind 28, 14, 7, 4, 2 und 1.

Sehen wir uns einmal praktisch eine solche Teiltabelle an, die nach Buchstaben sortiert ist.

Wir fangen in der Mitte mit dem Suchen an, und nehmen als Startwert drei, denn die Anzahl der Befehle ist sechs. Also die Mitte mal vier (Ein Adresse besteht aus vier Byte) und eine Addition von Tab, und wir haben den Pointer auf den ersten zu vergleichenden Befehl. Das wäre BRA. Nun werden mit einer Stringvergleichroutine die Zeichenketten überprüft. Liefert der Vergleich das Ergebnis, String kleiner, dann halbieren wir und suchen weiter. Ist der String größer so halbieren wir ebenfalls (einmaliges shiften nach links) und addieren es zur Mitte in. Wenn der Befehl gefunden ist, hören wir selbstverständlich auf.

Dieses Suchverfahren ist schnell, hat allerdings immer noch den Nachteil, dass der String mit vielen anderen verglichen werden muss. Es muss immer noch das Suchen nach dem String mit den passenden Anfangsbuchstaben durchgeführt werden, und mit passenden ersten Zeichen die folgenden verglichen werden, usw. Das bedeutet z. B. beim ILLEGAL Befehl immer noch ein Vergleichen um sieben Zeichen (obwohl diesen Befehl sowieso keiner braucht). Auch wenn ein Makroname mit ILLEGAL_Adresse gewählt wurden, muss noch 8-mal verglichen werden, um zum Schluss zu kommen: Oh, kein Schlüsselwort!

Kleiner Trick an dieser Stelle: Strings von hinten an zu untersuchen kann schneller sein.

Die dritte Möglichkeit:

Eine weitere Suchmöglichkeit wäre ein Hash-Algorithmus. Der Trick dabei ist, über ein Suchschlüssel die Wörter zu identifizieren. Einfaches Beispiel: Eine Vorauswahl kann über die Stringlänge erfolgen. Die Tabelle enthält dabei als ersten Byte die Stringlänge (Befehle länger als 255 Zeichen sind mir nicht bekannt (oder dem Leser vielleicht?)) und dann folgen die eigentlichen Zeichen. Ein Zeichenkettenabschluss mit dem Nullbyte ist nicht mehr nötig, denn um das Ende zu erreichen, addieren wir die Stringlänge auf den Anfangszeiger des Strings, und schon sind wir beim nächsten Tabelleneintrag, der erneut mit der Länge beginnt. Beim Suchen kann anhand der Länge, die entweder 2 (OR, ST, Assemblerschlüsselwort, z. B. dc, ds), 3 (NOP, EXT), 4 (MOVE), 5 (MOVEM, RESET, TRAPV), 7 (ILLEGAL) eine Auswahl der Befehle erfolgen.

Doch überdenken wir einmal ernsthaft diese Technik. Bringt sie beim Suchen überhaupt etwas? Die Antwort ist einfach, und kann verneint werden. Da sowieso fast alle Befehle drei oder vier Zeichen haben, kann man sich die Suchtechnik ersparen, Befehle wie ILLEGAL oder RESET kommen höchstens ein, zwei mal im ganzen Quelltext vor, beim sequentiellen Suchen lassen sich diese Befehle auch ganz hinten finden. Na ja, mit der Vorauswahl war’s wohl nix. Ich möchte dennoch nicht unerwähnt lassen, dass bei ASCII Texten dieses Suchen dennoch effizienter als sequentielles Suchen ist, denn dort finden wir Wörter mit verschiedenen Längen, und die Vorauswahl bringt Geschwindigkeit ein, wenn man nur diese Satz anschaut wird es einem klar, er enthält nicht nur Wörter, die durchschnittlich 3 oder 4 Zeichen lang sind, sondern auch viele Wörter mit mehreren Buchstaben.

Hash-Suche

Das Beispiel mit der Längeangabe gehört nicht ganz zum Hash-Sort, macht aber die Idee deutlich, über bestimmte Merkmale zum Befehl zu kommen. Allerdings ist die Länge dabei kein eindeutiges Merkmal jedes Befehles, sondern es existieren oft mehrere Befehle mit gleicher Länge. Und nach der Vorauswahl muss immer noch sequentiell die Tabelle mit Mnemoniks gleiche Länge durchsucht werden.

Dem Programmierer muss es nun gelingen, eine eindeutige Zuordnung zu finden, sodass das ASC-Suchen ersetzt werden kann.

Nehmen wir als Beispiel an, unser Prozessor hätte vier Befehle:

Bei der Erkennung von SUB kann nun direkt daraus geschlossen werden, drei Zeichen d. h. in einer Tabelle mit Sprungadressen die dritte Adresse nehmen, und zu ihr springen. Jetzt ist aber das Problem der Längengleichheit, was tun? Wir könnten die Buchstaben nehmen, und miteinander verknüpfen (durch odern der ASCII-Zeichen)! Bei zwei Befehlswörtern, z. B. MOVE und MULU sind jetzt die Werte, die durch Verknüpfung entstanden sind, unterschiedlich. Da bei der Separation direkt ein Verknüpfungswert ermittelt werden kann, benötigen wir kein ASCII-Suchen und Vergleichen mehr, sondern nur ein Suchen in einer Tabelle mit Verknüpfungswerten. Diese Werte können nun geordnet vorliegen, und über binärem Suchen ist schnell eine Zahl gefunden, die als Index zu einer Tabelle verwendet werden kann.

Ein Beispiel zu dieser vierten Technik, mit fiktiven Verknüpfungswerten:

Geordnet in einer Tabelle, wenn man binär sucht (sonst natürlich auch beliebige Anordnung, wenn sequentiell gesucht werden soll):

Taucht im Quellcode ROR auf, so ermittelt der Assembler den Verknüpfungswert 102. Das geht auch ohne ihn vorher in einen Puffer zwischenzusichern. In der Werte-Tabelle wird nun nach dem Teilungsverfahren gesucht, und die Adresse ROR_Up ermittelt. Dorthin springt der Assembler, und fertig. Noch ein weinig schneller geht es, wenn zu jedem Schlüsselcode (0-65536) eine Sprungadresse existieren würde, aber das wäre in der Praxis etwas zu lang. Ein in ein Word codiertes Wort (schwierig, schwierig) würde dann ein einziger Eintrag aus einer Tabelle mit der Größe von 64 KB sein, und wer spendiert das schon?

So gut wie die Routine auch sein mag, Nachteil hat sie natürlich auch. Die liegt aber nicht am Prinzip, sondern an der Einfachheit. Einige Beispiele, woran unsere Routine scheitert:

MOVE, MVOE, MEOV, MEVO, EVOM, und so viele mehr

Alle enumerierten Wörter werden gleich angesehen. „Verständlich“, wird man sagen, denn beide ergeben denselben Verknüpfungswert, die gleichen Buchstaben werden ja benutzt. Also, was tun? Ganz einfach, man muss die Position, an der das Zeichen steht, mit einem Definitionswert verbinden, also die Position mit verschlüsseln. Etwas so:

Wenn man jetzt die Reihenfolgen der Buchstaben ändert, ändert sich automatisch der Schlüssel mit.

Nachdem nun mittels eines Codes die zum Befehl gehörige Sprungadresse ermittelt wurde springen wir unser Befehlsunterprogramm an. Dort wird der entsprechende Opcode in den Speicher geschrieben, und der Befehlszeiger zwei Byte weiter gesetzt, um die nächste(n) Bitkombination(en) anzufügen.

Etwas komplizierter wird die Programmierung der Unterprogramme bei Übergabeparametern. Wir beginnen mit Befehlen, die einen konstanten Ausdruck fordern. Konstante Ausdrücke sind z. B. in der Form 3 + 4 - %101 im Quelltext anzutreffen. Es können jedoch auch Variablen oder Konstanten in den Term eingebaut werden, sodass diese Werte mit in die Berechnung einfließen müssen. Der Assembler muss aufgrund dieses Problems der zusammengesetzten mathematischen Ausdrücke über einen Parser verfügen, der diese Einzelausdrücke auswertet. Dies erschwert die Programmierung ungemein, denn Parser mit Auswertroutinen sind im Regelfall rekursiv, und somit aufwendiger in Assembler umzusetzen.

Ist der Ausdruck einmal ermittelt, kommt das zweite Problem. Der Absolutwert muss in irgendeiner Form im generierten Code untergebracht werden. Generell bieten sich dazu zwei Möglichkeiten an.

Bei der zweiten Realisierung besteht die Programminformation aus zwei Words, wovon das Erste (vielmehr die ersten vier Bit) die Kennung, und das Zweite die Information darstellt. Nach der Realisierung von Typ a) werden die Informationsträger im Hauptword untergebracht, sonst angehängt.

Unser Motorola Chip benutzt bei Befehlen beide Darstellungsarten.

Es handelt sich dabei als erstes um den TRAP Befehl. Der Aufruf ist bekannt, als Übergabeparameter eignen sich die Werte von $00 bis $0f, denn die CPU erlaubt nicht mehr als 16 Vektoren. Um eine Palette von 16 „Fallen“ zu erlauben, sind 4 Bit 2⁴ = 16) erforderlich. Aufnahmeplatz für diesen Wert findet man in den letzten vier Bit des TRAP-Opcodes.

Ebenso befinden sich zwei Relative Sprungbefehle in der Tabelle, BRA und BSR. Sie sind insofern etwas besonderes, als dass sie gleichzeitig zur Kategorie a und b zählen. Bekannt ist, dass bei relativen Sprüngen Kurzformen existieren, wenn der Sprungbereich klein ist. Sie kennzeichenen sich durch die Endung .s aus, und haben eine Ersparnis von 2 Bytes und bringen etwas Geschwindigkeit ein. Bei Nichtbenutzung der Kutzform erweitert sich die Programmlänge um zwei Bytes, der Sprungbereich kann aber auf +-32 KB ausgeweitet werden. Ein Nicht-Shorty kostet also 4 Bytes im Gegensatz zum Shorty mit 2 Bytes.

Die CPU hat jedoch einige Probleme die Relativ-Shorties zu erkennen und sie von weiten Sprüngen zu unterscheiden, denn man sieht, dass der Anfang mit der Bitkombination %01100001 bzw. %01100000 derselbe ist. Um daher einen Shorty zu erzeugen belegt man die unteren acht Bit des Opcode-Word mit der relativen Adresse und erreicht Sprünge von +-128 Bytes. Ist dieses Byte Null, so handelt es sich um einen weiteren Sprung im Adressbereich von +-32 KB. Die nachfolgenden 16 Bit im Programmcode sichern dann den Distanzwert, wobei der Wert vorzeichenbehaftet sein kann, um eben Sprünge nach vorne und hinten zu erzeugen. (Es wäre ja traurig, wenn man nur nach vorne springen könnte!).

Meines Erachtens ist das Null-Byte aber eine Vergeudung, und es macht mich traurig, dass zur Identifizierung eines Shorties ein ganzes Nullbyte benötigt wird. Ich möchte gern einmal einen Entwickler sprechen, der mir dies erklären kann. Es wäre um einiges sinnvoller gewesen, wenn für weite Sprünge einen Distanzwert von 24 Bit erlaubt würde. Um die Sprungbefehle dann zu unterscheiden zu können müsste man allerdings einen neuen Opcode festsetzen, doch was macht das schon aus, die Nobel-Prozessoren 68040/68050 sind sowieso viel Befehlsbepackter? Der Gewinn dieser Konstruktion wäre fantastisch, und die JMP/JSR Befehle wären somit fast passe. Und noch ein weiterer unverkennbarer Vorteil: Das Multitasking und seine verschiebbaren Programme. Welcher Computer kennt nicht die Last, erst einmal die JMP Adressen umzurechnen, damit das gleiche Programm auch 20 Bytes weiter läuft?

Neben diesen Vorteilen, ein Nachteil für den Prozessor: Er müsste diesen Distanzwert erst ausmaskieren, und die Datenbearbeitung würde zusätzliche Verarbeitungszeit kosten, aber was soll’s, ich glaub schon, dass das drin wäre.

Als Assemblerprogrammierer von Assemblern hätten wir auch keine Schwierigkeit, die Befehle mit konstanten Übergabeparametern zu einem Programm anzuhängen. Ein Ablaufschema ist etwas so denkbar:

Eine Codegenerierung ist einfach, denn der Absolutwert erscheint in den letzten Bit, sodass auch eine Verschiebung der Konstanten Werte im Opcode entfallen kann. Wenn sich in A5 ein Zeiger auf freien Speicherplatz befindet, in D0 der Absolutwert und in D7 der Opcode, so würden die Zeilen für einen kurzen Sprung folgendermaßen lauten:

Für einen nicht optimierten Sprung, der einen größeren Bereich einnimmt, könnte das Listing so lauten:

Die Technik, wie absolute Zahlen gesichert werden, ist beispielhaft und grundlegend für weitere Befehle, denn anstatt eines Absolutausdruckes kann auch ein Datenregister stehen. Überlegen wir, welche Änderungen notwendig wären. Auszuschließen ist zunächst das Ablegen der Information im zweiten Word, denn um eine Registernummer anzusprechen werden lediglich 3 Bit (2³ = 8) benötigt, eine Verschwendung von 16 - 3 = 13 Bit wäre Wahnsinn.

Es bleibt die Möglichkeit die Registernummer in drei freie Bit unterzubringen. Ein Freiraum ist in der Tabelle mit drei Strichen gekennzeichnet.

Der Befehl „weiß“ dabei selbst, ob ein Adress- oder Datenregister benötigt wird. Eine Zusatzinformation kann demnach also entfallen.

Ein Beispiel für Befehle mit Registern ist der SWAP Befehl. Er verlangt ein Übergaberegister, dessen Inhalt eine Teilword Austauschaktion mitmachen soll. Von den Entwicklern ist jedoch nur ein Vertausch in Datenregistern vorgesehen. Wenn allerdings eine weitere Information (gesetztes, ungesetztes Bit) zur Verfügung stände, so wäre ebenso ein Vertausch im Adressregister denkbar. Die Entwickler planten dies nicht ein, und auch nach reiflicher Überlegung wird man kaum Anwendungen finden, in denen ein Verlangen nach Adressword-Vertauschen aufkommt.

Ebenso ist der UNLK Befehl in der Tabelle aufgeführt, der den mit LINK angelegten Lokalstack aufhebt. Als Übergaberegister wird eins der acht Adressregister erwartet.

Entsprechendes Unterprogramm zur Verwaltung der beiden Befehle wäre schnell formuliert:

Nun kommen verzwicktere Befehle, die zwei Übergabewerte verlangen. Dies wird im Folgenden ein Register und ein Absolutwert sein.

Zwei diese Fälle sind in der Auflistung zu finden.

Eine Mischung von Registerwert und Absolutwert ist LINK, das Gegenstück von UNLK. Einleuchtend, dass auch dieser Befehl ein Adressregister verlangt. Daneben muss für die Einrichtung eines Lokalstacks die Größe des Adress-Offsets angegeben werden. Der Größenbereich bewegt sich innerhalb eines Words, positive und negative Zahlen sind erlaubt, allerdings sind nur negative sinnvoll.

Der angegebene Distanzwert wird nach dem mit Registereintrag versehende Opcode gesichert.

Ein Unterprogrammauszug:

Anders als beim LINK Befehl werden die Absolutwerte bei MOVEQ gesichert. Durch die Restriktion, dass die Werte nur eine Breite von 8 Bit einnehmen können, ist die CPU in der Lage, diese in den Opcode unterzubringen. Die Vorteile sind: Geschwindigkeit bei der Ausführung und 16 Bit bei der Speicherplatzbelegung. Bei dem MOVEQ finden wir auch eine Eigenschaft wieder, die bei den kommenden Befehlen häufiger zu finden sein wird. Die Registernummer wird ab Position 9 im Word abgelegt. Bei einer Länge von drei Bit bedeutet das einen Belegung von Bit 11, 10 und 9. Für uns Programmierer heißt dies: Das Datenregister Nr. x um 9 Positionen nach rechts schieben. Als ehrgeizige und sparsame Assemblaner wissen wir aber auch, dass siebenmaliges linksrotieren vom Prozessor schneller durchgeführt werden kann als neunmaliges Rechtsschieben. Hier kommt uns die CPU Fähigkeit insofern entgegen, als das die Bit, die rechts herausfallen, links wieder reingeschoben werden.

Explizit ist bei der Parameterübergabe zu beachten, dass die Absolutzahl ein vorzeichenbehaftetes Byte sein kann. Jedoch ist mancher Programmierer fix mit den Fingern, und denkt nicht an eine Beschränkung der positiven Zahlen bis 127, denn Werte, die höher sind, werden von der CPU als negative Zahlen angesehen, und dementsprechend auf negative Longs erweitert (so wie alles auf Longs ausgedehnt wird). Unter diesem Aspekt sollte der Assembler eine Warnmeldung auszugeben, wenn der Bereich von 0-127 überschritten wird. Fehler, die sich bei Zeilen wie

einschleichen, erübrigen sich somit. Ist der Assembler „klug“, so erscheint bei Übergabeparametern mit führendem Minus keine Fehlermeldung, obwohl die Werte hoch sind, denn ein negativer Wert war beabsichtigt. Es wäre vergeudete Bildschirmausgabe, wenn der Programmierer bei Ablegung der Booleschen Variablen TRUE = -1 in ein Register eine Warnung erhalten würde.

Ein Unterprogramm, welches MOVE-Quickies verwaltet, hätte etwa folgenden Aufbau:

Es gibt welche, die haben einen, andere haben zwei davon. Die Rede ist von Registern, die Befehlen übergeben werden. Das heißt allerdings für den folgenden Befehl nicht, dass der zu verarbeitende Wert aus einem Register kommen muss. Um das zu verstehen erst einmal einen Blick auf den Befehl selbst.

Von CoMPareMemory existiert dabei nur die Version:

Jetzt wird verständlich, warum ich Register meinte, aber keinen Registerwert. Da von diesem Befehl sowieso nur eine Indirekt mit Postdekrement Version existiert, können wir uns Angaben über die Adressierungsart sparen. Es ist lediglich von Wichtigkeit, welches Adressregister als Basis genommen wird.

Im Befehl wird die Information folgendermaßen gesichert: Ab Bit 9 wird das Ziel-Adressregister, und ab Bit 0 das Quell-Adressregister abgelegt. Die beiden Bit in der Mitte sind zur Längenangabe verurteilt, die entweder 00, 01 oder 10 ist.

Zum Einlesen der Operandengröße ist ein zweckmäßig eine Funktion zu definieren, die diese Aufgabe übernimmt. Sie könnte etwas wie folgt aussehen, unter der Annahme, dass die Befehle schon erkannt wurden, und der Zeiger auf dem nächsten Zeichen im Quelltext steht. Im Regelfall ist das folgende Zeichen ein Punkt (Operationslänge), ein Semikolon (angefügte Bemerkung), Leerzeichen oder Tabulator (Werte folgen) oder ein Return (bei einem Befehl ohne Parameter).

Das folgende Unterprogramm sucht nach einer Endung, und schreibt die OpLänge als Kürzel ins D0 Register. Als Pointer auf den ASCII-Text habe ich das A4-Register gewählt.

Zum Unterprogramm muss noch folgendes gesagt werden: Da im Übergabeparameter D0 die Kennzeichnung (00 = Byte, 01 = Word, 10 = Long) stehen soll, kann eine Null nicht für Unbekannt stehen (Im Regelfall liefert eine Funktion als Rückgabeparameter Null für Falsch, -1 (oder 1) für Wahr), da die Kennung für ein Byte notwendig ist. Somit ist es notwendig eine andere Bitbelegung einzuführen. Anbieten würde sich -1. Der Sprung muss dann abgeändert werden, und aus einem „beq Fehler“, wird ein „bmi Fehler“. Zunutze machen wir uns hierbei eine Auswahl von 3 Möglichkeiten: Null, ungleich Null, und negativ (7./15./31. Bit gesetzt). Da der Benutzer durch solcherlei Umdefinierungen - mal ist Null ein Fehler, dann wieder -1 - ins Schleudern kommen kann, sollte dies auch nicht zu häufig angewandt werden.

Auch dieser Befehl kann leicht verarbeitet werden. Ist er erkannt, holt der Assembler die Länge und verknüpft sie. Jetzt muss sichergestellt werden, dass ein "(a" folgt. Bei wahrer Aussage holen wir den Registerwert und verknüpfen ihn mit dem Opcode. Folgt nach der Zahl 0-7 eine Zeichenkette "),(a" ist die nächste Zahl zu holen, und um sieben Positionen nach links gerollt mit dem Opcode zu verknüpfen. Beim richtigen Abschluss mit ")" kann die Bitfolge gesichert werden.

Mit den drei noch kommenden Befehlen verabschieden wir uns von den einfachen Befehlen, deren Umsetzung keine Probleme bereitet. Kleine Routine, sequentieller Ablauf, stimmt etwas nicht, Fehler.

Die Mnemoniks, die noch nachhoppeln sind einfach wie ihre anderen Befehle auch, aber in einer bestimmten Weise auch Wegbereiter für die kommenden. Dies liegt daran, dass die flexibler in ihrer Anwendung sind.

Beim SBCD- und ABCD-Befehl fällt zunächst ihre Abstammung auf. Beide sind Funktionen aus dem Bereich der BCD-Verarbeitung. Da dieses Anwendungsgebiet auch nicht allzu oft angeschnitten wird, spendierten die Entwickler auch nicht viele Adressierungsarten. Lediglich zwei Adressierungsarten sind drin.

oder

Bei Betrachten der beiden Befehle finden wir sieben freie Stellen. Sechs können wir zuordnen. Drei Bit für das Zielregister und drei Bit für das Quellregister ergeben diese Summe. Doch wofür das Übrigbleibende? Da die Information über die Länge entfällt, kann die eine Informationseinheit zur Angabe der Adressierungsart genutzt werden. Es wird definiert, dass ein gesetztes Bit an Position drei als Adressregister, andernfalls bei nicht gesetztem Bit als Datenregister interpretiert wird.

Bei beiden Befehlen erscheint an Position 9 das Zielregister und an Position 0 das Quellregister.

Ebenso durch einen Modus erweitert, präsentiert sich uns der EXG-Befehl. Da beim Vertauschen der Registerinhalte zunächst die zweimal drei Bit zur Registerspezifikation benutzt werden, und fünf andere vordefiniert sind, bleiben fünf freie Bit. Um das zu verstehen, eine Liste der Möglichkeiten, welche Kombinationen möglich sind. Da nur eine Langword-Operation möglich ist, schrumpft die Zahl deutlich.

Wir sehen: Die Information, durch welche Registerklasssen die Werte vertauscht werden, ist zwingend notwendig. Jedoch bei drei Möglichkeiten die sich ergeben, und dazu zwei notwendigen Bit, werden zur Dekodierung fünf Bit benutzt, gerade die Zahl der Bit, die noch frei sind.

Sollte also der Befehl EXG A6,D2 dekodiert werden, ergibt sich:

Ebenso bedient sich der ADDX bzw. SUBX Befehl der was-bin-ich-Bit-Technik. Denn wie beim ABCD sind nur zwei Adressierungsarten erlaubt, nämlich

oder

Ist das achte Bit gesetzt, so wird als Adressierungsart Register Direkt benutzt, andernfalls Adressregister Indirekt mit Dekrement.

An den Bitpositionen 11, 10 und 9 steht das Zielregister, an der Stelle 2, 1 und 0 das Quellregister. Zwei Stellen bleiben jetzt noch unbesetzt, hier wird die Operandenlänge eingesetzt.

Der MOVEQ ist ein oft und gern genommener Befehl. Es zeichnet sich hier schon ab, dass Übergabeparameter auf den Opcode verteilt werden, um Platz zu sparen, und den Prozessor nicht zusätzlich zu einem Lesevorgang zu bewegen, der nur Zeit kostet.

Das Feld mit Registern und Absolutwerten ist mit den beschriebenen Befehlen abgedeckt, und es folgen Opcodes, die neben der Registerzahl und Absolutaufnahmen noch einiges mehr aufnehmen.

So beim ersten Befehl EXT bzw. EXTB, zweitens nur von Prozessoren 68020 und höher unterstützt. Es lässt sich mit diesem Befehl das Ziel vorzeichenerweitern.

Die Registernummer findet wieder Obhut in Bit 2,1 und 0. Wachsame entdecken drei weitere freie Bit an Position 6, 7 und 8. Es ist eine Befehlserweiterung, die sich durch die Anzahl der Striche verrät. Es handelt sich um die Operantenlänge, eine Informationszunahme, die auch bei anderen Befehlen beobachtet werden kann. EXT erlaubt die Endung .w und .l, EXTB auch .l. Das Ziel ist immer ein Datenregister, Adressregister würden überhaupt keinen Sinn machen. In diesem Freiraum trägt man den Modus ein, der nach folgender Tabelle codiert ist:

Leider benutzt der EXT(G)-Befehl eine andere Längenkennung als unser Unterprogramm liefert. Die meisten Befehle, die eine Ergänzung um die Oplänge haben, weisen eine feste Position im Erkennungsword und eine vordefinierte 2-Bit Kennung zur Identifikation der Endung .b, .w und .l auf. Für den EXT-Befehl gelten sie jedoch nicht, und müssen umdefiniert werden. Die Vorgehensweise ist einfach:

Das Unterprogramm zum EXT-Befehl, welches die Längen benötigt, ruft zunächst einmal HolOpLänge auf, in dem die Längen nach Standart ins D0-Register geholt werden. Bei erfolgreicher Erkennung dieser kann der D0-Inhalt in den Modus umgewandelt werden. Die Vorgehensweise zeigt die kleine Tabelle.

Wie immer gibt es mehrere Möglichkeiten die Längen in den Modus umzuwandeln. Als erstes die CMP-Methode, jede Oplänge wird verglichen, und einem Modus zugeordnet, oder der Modus wird aus einer Byte-Tabelle ermittelt, indem die OpLänge der Feldindex ist. (Er eignet sich gut, denn 00, 01 und 10 sind nichts anderes als 0,1,2 in dezimaler Schreibweise.)

Aufgabe: Es soll ein EXT.L D4 dekodiert werden.

Lösung:

Etwas spannender in der Kodierung wird es mit Befehlen, die eine cc-Endung haben. Als Beispiele für diese Mnemoniks sind in der Tabelle Bcc und DBcc genannt. Fast schon mit Langeweile können wir die Information entgegennehmen, dass auch die cc’s über zugehörige Bitwerte verfügen. Da die Kennung nur 4 Bit lang ist, kann sie im Opcode-Word untergebracht werden.

Bevor es ins Befehlsdetail geht, die Tabelle:

Es fällt auch nach näherem Betrachten kein Zusammenhang der Condition Codes ins Auge. Einzig wären Zusammenhänge in der Bitabfrage zu finden, denn komplexere cc’s wie GE, LT, GT und LE, am Ende der Tabelle stehend, reagieren auf mehrere Kondition-Bit. Außer HI und LS machen diese keine anderen Endungen. Ob dies nun als Zusammenhang festgehalten werden kann, muss jeder für sich entscheiden.

Weitsichtig lässt sich ein Unterprogramm formulieren, welches, wie bei den Operationslängen, die Endungen entschlüsselt. Im Folgenden eine Möglichkeit, wie’s mit dem Zeiger in A4 auf einen String gemacht werden könnte. Nach dem Verlassen der Routine steht entweder der Bitwert in D0 oder eine negative Zahl, einfacher halber -1, die anzeigt, dass die CC-Kennung nicht gefunden wurde.

Nachdem die Endungen erkannt und die Bitkombinationen in D0 stehen, kann weiter gehen.

Aus den Opcodes lassen sich über die Belegungen wenig Aussagen machen. Es geht nun um die Auflösung. Die cc-Bedingung ist in Bit 11, 10, 9 und 8. Nach erfolgreichem Finden der cc-Endung rollen wir das D0-Register 7-mal nach rechts und or-en es mit %0110000000000000. Fast fertig. Was dann noch folgt ist alter Kram, denn es ist äquivalent zum BRA/BSR Ausgang. Label holen, relativieren, ist er im Bereich +-128 Bytes dann Shorty, wenn nicht dann Lo-Word vom Erkennungsword mit Null belegen, und die Sprungadresse im Folgeword. Ganz simpel.

Extremisten, die die CC-Abfrage-Technik als zu langsam empfinden (ich bin auch so einer!), obwohl die cc’s weiter für Scc oder DBcc benutzt werden können, haben die Möglichkeit, die Befehle einzeln zu definieren. Mit einer eigenen Unterprogrammadresse lassen sich dann ein übergeordnetes Programm anspringen, das dann mit den Opcodes die weiteren Verrenkungen macht.

Die Anordnung der Sprungadressen dürfe klar sein, und dass folgende Demolisting zeigt, wie die Verwaltung der einzelnen Bcc-Befehle möglich wäre.

Machen wir mal einen Aufmerksamkeitsversuch. Man nehme die Bcc-Konstante %0110000000000000. Nun verknüpfen wir dies mit der cc-Kennung „T“ (True) %0000. Wir erhalten %0110000000000000. Jetzt schauen und mit schon bekannten Opcodes vergleichen! Und? Ei, da sieh mal einer an, die Kennung stimmt mit der von BRA überein. Dies mag verständlich erscheinen, denn ein BT ist ein BRA, denn da die Bedingung immer Wahr ist, kann auch ein Sprung immer ausgeführt werden. Überhaupt keinen Sinn ergibt sich allerdings, wenn wir %0110000000000000 mit „F“ (wie BF) verknüpfen. Das Ergebnis %0110000100000000 stimmt mit dem Opcode von BSR überein. Aber wo liegt da die Logik?

Ein Assembler kennt 16 verschiedene Kondition-Kodes. Mit dem Zweideutigen Condition Code CC/HS bzw. CS/LO kommen wir auf 18 verschiedene Endungen. Sollte man der Einfachheit halber eine Alround-Routine zum Auswerten benutzen, dann muss entsprechend auf den Sonderfall BRA/BT und BSR/BF geachtet werden, denn ein BT ist möglich und bedeutet nichts anderes als ein BRA, aber bei einem BF muss eine Fehlermeldung ertönen, denn ein BSR wird nicht beabsichtigt sein. In einem Unterprogramm zur Auswertung und Weiterleitung kann aufgrund dieses Problems nicht jeder cc unkontrolliert verarbeitet werden. Viel mehr ist darauf zu achten, das ein Fehler, möglicherweise wegen eines Tippfehlers, auffällt.

Nach dem Bcc und auf zum nächsten Befehl, DBcc. Er unterscheidet sich im Aufbau erheblich, einzige Gemeinsamkeit die führende Kennung %01 und die Kondition Kodes an Position 11, 10, 9 und 8. Hier sind nun endgültig alle cc’s erlaubt, und einige Programmierer verwenden immer ein DBF, wenn ich stattdessen DBRA schreibe. Aber es ist eine reine Gewöhnungssache, man kann’s machen wie man will, es ist sowieso der gleiche Befehl, und wir verstehen jetzt auch warum. Ehrlich gesagt dürfte es einen DBRA auch gar nicht geben, denn RA ist kein cc. Es hat sich allerdings so eingebürgert, so dass unser Assembler hier wieder schlau sein muss.

Da im Gegensatz zum Bcc-Befehl ein Zählregister hinzukommt, muss dementsprechend Platz für 3 Bit geschaffen werden. Sie finden ihren Platz gewohnter weise an Position 2, 1 und 0. Diese Tatsache schließt allerdings etwas aus. Der DBcc-Befehl erlaubt keine Shorties. Die untersten Bit sind belegt, und Platz für 8 Bit findet sich nicht mehr. Die jetzt unbenutzten fünf übrigen Bit werden aber nicht mit Nullen aufgefüllt, sondern mit dem Bitfeld %11001. Dies hat einen Grund. Um den zu verstehen vergleichen wir einmal

und

Heu, das wird knapp. Um die Spannung in die Höhe zu treiben: Wie werden wohl die zwei Bit vom Subi noch zu belegen sein? Nun, die Information über den Suffix fehlt noch. Da die Länge nur 00, 01 oder 10 sein kann, bleibt nur noch 11, um die beiden Befehle zu unterscheiden. Es liegt nun nur am gesetzten sechsten Bit, ob ein DBF oder SUBQ (noch mit ihrem Gedöns dran) compiliert wird. Dies zeigt die wichtige Aufgabe eines Programmierers, auf die Bit zu achten, und keinen Fehler im Abschreiben (!) zu machen. Das testen des Assemblers dauert dementsprechend lange, denn Verknüpfungen müssen einfach stimmten, und es darf nicht vorkommen, dass hin und wieder ein Bit nicht ausmaskiert wurde.

Bisher waren die Befehle von keiner komplexen Struktur. Wir hatten keinen Übergabeparameter, wenn, dann einen, selten zwei, und dann einfache, durchschaubare. Durch eine Modusangabe wurden die Befehle dann um Befehlsmöglichkeiten erweitert.

Wenn wir uns im Gegensatz zu den einfachen Befehlen einmal die Konstruktionen mit komplexeren Adressierungsarten, wie

anschauen, so kommt etwas zum durchscheinen, was bei allen Mnemoniks bisher noch nicht auftrat. Bisher waren die Adressierungsarten nur Register direkt, oder Adressregister indirekt. Mit den vielfältigen Befehlsmöglichkeiten ändert sich dies, und die Information über diese Adressierungsart muss ebenso wie die Registernummer im Opcode gesichert werden.

Neben den phantastischen Eigenschaften der CPU alle Register gleichberechtigt zu halten, sinkt man auch nicht so auf das Intel Niveau herab, wo noch immer gilt: Lieber ein Register zum Zählen, eins zum Rechnen, und eins, wo wir unsere Adressen ablegen. Die Stärke, die unser Motorola Chip aufweist, ist besonders die Orthogonalität. Bei den meisten Befehlen können mehrere Adressierungsarten angewendet werden, die Register sind allgemein, spezielle Registerbindungen an Befehle gibt es nicht.

Einmal bei den Adressierungsarten angelangt kommt man zu dem Schluss, dass die Mnemoniks kombiniert mit den Adressierungsarten sehr viele Möglichkeiten bilden. Und dann kommt man zu dem Schluss: Da muss eine Technik hinter stecken! Denn so wie früher mit Modi-Bit ein oder zwei Adressierungsarten zu unterscheiden, ist absurd.

In den ersten Kapiteln des Buches wurden die verschiedenen Adressierungsarten ausreichend erläutet, sodass nun die Thematik behandelt werden kann, wie sie dekodiert werden.

Wenn die Antwort Modi-Bit lautet (gesetztes Bit, Möglichkeit b, sonst a) liegen wir schon ganz gut. Das Verfahren zur Unterscheidung der Adressierungsarten ist aber etwas komplexer und ausgedehnter, denn nun gilt es nicht mehr unter Ja/Nein Zuständen zu unterscheiden, sondern unter mehreren Adressierungsarten zu unterscheiden.

Die eigentliche Information über die Adressierungsart liegt in drei bzw. sechs Bit verborgen. Die ersten drei Bit werden Modus genannt, und durch die Angabe einer Zahl von %000 (0) bis %111 (7) angegeben. Die zweiten drei Bit nehmen, wenn möglich, Register auf. Wenn keine Register-Informationen vorliegen erweitern die drei Bit den Modus. Zusammengesetzt aus Modus plus Register ergeben die sechs Bit eine Kombination, den man Effektive Adresse (EA) nennt.

In der Tabelle wird dieser Zusammenhang allerdings besser sichtbar, denn sie beschreibt mögliche Adr. Arten und ihre Bitbelegungen in Modus und Register.

Zur Übung basteln wir ein paar EAs zusammen:

Bei den Befehlen, die in der Tabelle folgen werden, handelt es sich nur um Mnemoniks die eine EA Angabe verlangen. Diese EA-Angabe spezifiziert selbstverständlich ein Ziel, und keine Quelle, denn Befehle, die nur eine Quelle haben, aber kein Ziel, gibt es nicht.

Die effektive Adresse benötigt sechs freie Bitplätze. In der Praxis sieht es so aus, dass die Opcodes sechs freie Bit am Ende aufweisen (Bit 5-0).

Wenn in der Tabelle neben den sechs freien Positionen noch zwei weitere auftauchen, dann sind Längenangaben erforderlich. Diese werden wie üblich in Bit 6 und 7 gesichert.

Wenn ein Befehl in seine Bitwerte umgesetzt werden soll, müssen alle Einzelinformationen, d. h. Informationen über das benutzte Register, die Operandenlänge, zusammengefügt werden.

Als Beispiel wähle ich folgenden Befehl, den wir von Hand kodieren wollen:

Aufgespaltet in die einzelnen Komponenten ergibt sich:

Ein Assembler versucht nun den Vorgang soweit zu automatisieren, dass ein Unterprogramm Hauptarbeiten abnimmt, so z. B. EAs auswerten. Es werden zur Generierung und Eintragung des Opcodes weitere Unterprogramm genutzt, die aber im einzelnen nicht weiter beschrieben werden.

Für ein Unterprogramm, das ein CLR auswertet, könnte der Code etwa so aussehen.

Das Prinzip ist nun für alle anderen Befehle dasselbe. Man überträgt den Opcode in ein Register (ich habe D7 gewählt), holt die Länge über das Unterprogramm HolOpLänge und verknüpft diese mit dem Opcode. Im Unterprogramm MergeZielEA wird dann die EA geholt und mit dem Opcode verknüpft.

Selbstverständlich ist diese Art das Unterprogramm zu gestalten noch nicht das gelbe vom Ei. Daher ist man geneigt, noch einfacher vorzugehen, soweit, dass man keine Unterprogramme mehr für die einzelnen Befehle hat, sondern nur noch Tabellen, in denen der Compiler eine Adressierungsart erlaubt, oder ausschließt. Für Befehle, die komplexer sind, z. B. MOVEM kann immer noch auf die Möglichkeit zurückgegriffen werden.

Etwas abgesondert in der Tabelle stehen die Rotations- und Schiebebefehle. Für sie gilt: Das Ziel ist eine EA, und als Quelle wird kein Wert angegeben, denn die Bewegung ist immer konstant eine Position.

Der Befehl wirkt kurz und knapp, etwa:

Bei machen Schreibweisen muss der Assembler aber „schlau“ sein. Das untere Beispiel macht dies deutlich.

Aus dieser eigentlich unerlaubten Zeile (wenn ein Absolutwert abgebenden ist, darf das Ziel nur ein Datenregister sein) muss folgende übersetzt werden.

Um noch einmal klarzustellen: Die besprochenen Verschiebe- und Rotationsbefehle, die mit einer EA arbeiten, nehmen keine Absolutwerte auf, und können auch um keine bewegen. Ihre Änderung ist konstant auf einmaliges Bewegen festgelegt. Jeder Befehl dieser Form ist 2 Bytes lang.

Apropos Bytes und Opcode. Nach einem Blick in die Tabelle finden sich sofort Auffälligkeiten in den Bewegungsbefehlen. Denn in Bezug auf ihre Adressierungsarten sind sie gleich, und warum sollte man da nicht Zusammenhänge finden? Zunächst folgendes: Bit 3/4 enträtselt den Bewegungsbefehl wie in der Tabelle angegeben.

Da es nur in zwei Richtungen abgeht, kann man sich vorstellen, dass auch hier ein Bit als Richtungsweiser verwendet wird. Und so ist es. Es gesetztes achtes Bit lässt die Wirkung nach links erfolgen, und ein ungesetztes Bit lässt nach rechts bewegen. Mit den drei Bitinformationen lassen sich die acht Scroller abdecken. Jede der drei Bit wird genutzt, und 3² verrät ebenso die Anzahl.

Da wir die EA nur als Ziel kennengelernt haben, ist es nun an der Zeit sie auch als Quelle einzusetzen. Die nächsten Befehle sind ein Mischmasch aus welchen, die EA als Ziel oder auch als Quelle einsetzen.

Bei Betrachtung fällt durchgehend ein Loch an der Position 9 auf. An dieser Stelle wird die Registernummer eingetragen, die mit dem Befehl gekoppelt ist. Es ist jedoch nicht sichergestellt, ob das Register als Ziel oder Quelle eingesetzt wird. Die Vergewisserung kommt dann beim Blick in die Tabelle.

Gönnen wir uns einen Blick „in“ die Befehle. Die Bit-Manipulations-Befehle (mit Ausnahme der relativen Sprungbefehle beginnen alle mit einem „B“) haben durchgehend an der Position 9 ihr benutztes Datenregister, das hier als Quelle benutzt ist. Bitveränderer, die Absolutwerte bearbeiten, folgen im kommenden Kapitel; sie belegen die drei Bit an der Position 9 anders.

Ausschlaggebend für den Bitmanipulationsbefehl ist somit Bit 6, 7 und 8. Zur Verdeutlichung ein Blick in die Tabelle.

Auffallend sind ebenso die dritte und vierte Grundrechenart. Bei der Multiplikation und Division werden lediglich Datenregister als Zieloperand zugelassen, die EA findet Verwendung als Quellspezifikation.

Ob die Operation signed oder unsigned durchgeführt wird, liegt am gesetzten bzw. ungesetzten 8 Bit.

Beim LEA Befehl ist, ebenso wie bei den oben genannten Befehlen, als Ziel nur ein Register erlaubt. Das Register ist natürlich kein Datenregister, sondern ein Adressregister. Wenn dies nicht so wäre, würde die Abkürzung auch nicht „Load Effective address to Address Register“ heißen!

Nun, der LEA-Befehl nimmt also die EA auf, allerdings nicht alle, denn der Befehl ist wählerisch. So sind folgende Kombinationen unerlaubt (Möglichkeiten durch Schrägstrich getrennt):

Es sind also nur EAs erlaubt, die indirekt sind, und keine Adressmodifikationen anleiten, wie die Dekrements.

Der CHK-Befehle, dessen Benutzung sowieso im User-Betrieb eingeschränkt ist, erlaubt es den Mnemonik-Generatoren, verschiedene Längen anzugeben. Doch für Prozessoren, die unter dem 68020 liegen, ist nur die Wordbreite benutzbar, die die Längenkennung %110 erhält. Die Privis (Leute, die privilegiert sind) können auch auf Langword Checken. Sie haben dann die Kennung %100 einzusetzen.

Bei den beiden Compare-Befehlen, die in der Liste auftauchen, sind nur die ersten vier Bit belegt. Die restlichen 12 haben somit andere Bedeutungen. Wie gewohnt finden wir unsere EA an Pos 0-5. Es sind alle Adressierungsarten erlaubt. Bei beiden Befehlen, CMP und CMPA gilt, dass das Ziel nur ein Datenregister oder ein Adressregister sein kann. Der Registerwert findet sich an Position 9 und belegt wie gewohnt 3 Bit. Übrig bleibt nun ein Loch von 3 Bit an der Stelle 6.

Die freien Bit bestimmen den Modus der Befehle. Da die Operandenlänge noch nicht erwähnt wurden, ist nachvollziehbar, dass sie durch den Modus repräsentiert wird. Leider sind die Modiwerte für die Befehle CMP und CMPA ungleich. So gilt für den CMP Befehl folgende Modus-Bitbelegung: