Zur Programmierung des 68881-Arithmetikcoprozessors gibt es ein Standardwerk - das Motorola User Manual. Das Buch geht zwar sehr ausführlich auf alle Details bis hin zu Interrupts aller Arten ein, die Informationen werden aber recht spärlich, wenn als CPU ein anderer Prozessor als der 68020 verwendet wird. Dieser Artikel soll nun zeigen, daß die Assemblerprogrammierung des Coprozessors auch mit einem 68000-Prozessor keine Hexerei ist. Das Ergebnis: ein extrem schnelles Programm zur Errechnung von Apfelmännchengrafiken.

Der 68881 (auch Floating Point Unit - kurz FPU genannt) wurde als Erweiterung zum 68020-Prozessor entwickelt, die Interfaces der beiden Prozessoren sind derart aufeinander abgestimmt, daß der 68020-Programmierer den Eindruck hat, einen einzigen Prozessor zu programmieren. Der Befehlscode, den der Assembler erzeugt, wird vom 68020 Prozessor analysiert, alle notwendigen Aktionen (vor allem das Lesen und Schreiben diverser Interfaceregister des 68881) zur Ausführung des Befehles am 68881 werden automatisch durchgeführt. Und um eben diese Interfaceregister muß sich der geplagte 68000-Programmierer selber kümmern.

Die Interfaceregister

Der 68881 hat neun Interfaceregister, von denen für einfachere Aufgaben aber nur fünf wichtig sind:

• das Controlregister, mit dem der 68881 betriebsbereit gemacht wird
• das Commandregister, mit dem der Code des gewünschten Befehles übermittelt wird
• das Conditionregister, mit dem der Code einer Abfragebedingung übermittelt wird
• das Operandregister, mit dem Daten zwischen CPU und Coprozessor aus getauscht werden können
• das Responseregister, mit dem der 68881

(1) das Ergebnis einer Abfragebedingung mitteilt
(2) von der CPU diverse Dienstleistungen anfordert (z.B. die Übertragung von numerischen Daten)
(3) der CPU den aktuellen Betriebszustand mitteilt (z.B. daß der Coprozessor noch mit einer Berechnung beschäftigt ist).

Auf die Aufgaben dieser Register wird im folgenden genau eingegangen. Die Register werden grundsätzlich wie Speicherplätze angesprochen, die Adresse ist vom Hersteller der Coprozessorerweiterung abhängig. Sofern der Prozessor über die von ATARI reservierten Adressen angesprochen wird, kann mit folgendem Befehl das Response-Register in das Register DO des 68000 gelesen werden:

Tabelle 1 enthält die Länge der fünf wichtigsten Interface-Register, den Adreßoffset von der Coprozessoradresse (die bei älteren 68881-Erweiterungen, insbesondere von Lischka Datentechnik, auch einen anderen Wert als SFFFA40 haben kann) und die erlaubten Zugriffsarten (Read/Write).

Die Daten-Register und das Zahlenformat

Neben den Control- und Statusregistern (ähnliche Funktion wie beim 68800) und einem Instruction-Adreßregister gibt es 8 Datenregister: in ihnen werden Fließkommazahlen in einem internen 80 Bit-Format gespeichert. Dieses Format wird vom Coprozessor für praktisch alle Berechnungen verwendet. Zur Kommunikation mit dem 68881 können die Zahlen in verschiedenen anderen Formaten übertragen werden - dabei erfolgt eine automatische Konvertierung in das gewünschte Format. Es existieren folgende sieben Formate: Integer Byte, -Word, -Longword, Real Single Precision. -Double Precision, -Extended Precision (das ist das interne Format) und Packed Decimal Real (die Zahl wird als Zeichenkette übertragen).

In diesem Artikel wird zur Datenübertragung nur das Real Double Precision-Format verwendet. Die Fließkommazahl wird dabei in 8 Bytes codiert: Bit 0 bis 51 werden zur Darstellung der Mantisse, Bit 52 bis 62 zur Darstellung des Exponenten, Bit 63 für das Vorzeichen verwendet. Der Wert der Zahl kann nach folgender Formel bestimmt werden:

(-1)^vorzeichen2^(exponent-1023)(1+mantisse/2^52)

D.h. der Exponent wird als Integerzahl interpretiert, die Mantisse dagegen als Bruch: die eigentliche Mantisse ergibt sich aus einer Division durch 2^52 und der Addition mit 1. Die Zahl 0 kann dargestellt werden, indem alle 64 Bits auf 0 gesetzt werden. Dazu gleich zwei Beispiele (die hexadezimalen Zahlen sind dabei zur besseren Lesbarkeit mit _ in Vierergruppen unterteilt):

5.390625 wird durch $4015_9000_0000_0000 dargestellt.

Bit 63=0 (positives Vorzeichen), der Exponent ergibt sich als 1025 ($401) minus 1023, die Mantisse als $5_9000_0000_0000 dividiert durch 2A52 plus 1, also:

5.390625 = 2^2 * 1.3475625

Ähnlich wird -0.33333333 als $BFD5_5555_5555_5555 dargestellt. Das Vorzeichenbit ist 1, der Exponent lautet 1021 ($3FD) minus 1023, die Mantisse $5_5555_5555_5555 / 2^52 + 1.

-0.333333 = (-1) * 2^(-2) * 1.3333333333

Das hier beschriebene Zahlenformat ist genormt (IEEE), sollte von allen C-Compilern als Format zur Übertragung von Fließkommazahlen verwendet werden und kann in manchem anderen Programmiersprachen durch eigene Funktionen generiert werden (z.B. Funktion DOUBLE{} in GFA BASIC 3.0). Die Genauigkeit dieses Formates beträgt etwa 15 1/2 Dezimalstellen, der Zahlenbereich liegt zwischen 10^307 und 10^-307. Da der Coprozessor intern mit einer noch höheren Genauigkeit (19 Stellen) rechnet, wirken sich Rundungsfehler praktisch nicht aus.

Der Befehlssatz

Der Befehlssatz kann inhaltlich folgendermaßen unterteilt werden: Befehle zum Datentransport, zur Ausführung arithmetischer Befehle, zur Abfrage von Bedingungen und zum Task-Wechsel/Trap-Handling. Die letzte Befehlsgruppe wird in diesem Artikel komplett ignoriert, von den anderen Gruppen werden hier einige Beispiele angegeben:

Mit dem Befehl FMOVE können Zahlen von der CPU in ein 68881-Datenregister, von einem 68881 -Datenregister zur CPU, und von einem 68881-Datenregister in ein anderes Datenregister übertragen werden. Mit FADD. FSUB, FMUL, FSIN, FSQRT können arithmetische Funktionen aufgerufen werden. FCMP dient zum Vergleich zweier Zahlen. Mit FBcc können Vergleichsbefehle ausgewertet werden (wie der Branch-Befehl Bcc des 68000).

Befehlscodierung mit 68020

Anhand eines Beispiels soll gezeigt werden, wie einfach die Programmierung des 68881 ist, wenn der Steuerprozessor ein 68020 ist.

Der Befehl

zur Addition zweier 68881 -Register wird von einem geeigneten Assembler in die zwei Binärcodes

umgewandelt. Wenn der 68020-Prozessor diese Codes verarbeiten muß, schreibt er an das Commandregister den Befehlscode (in diesem Fall $A2) liest anschließend das Responseregister und wertet dieses aus. Genau um diese Dinge muß sich der 68000-Programmierer selber kümmern. Bevor darauf im Detail eingegangen wird, müssen aber einige der Interfaceregister näher beschrieben werden.

Das Controlregister

Ein Schreibzugriff auf dieses Register bewirkt unabhängig vom Wert den Abbruch eines eventuell noch in Arbeit befindlichen Befehles. Außerdem wird für das Interface des Coprozessors ein Reset durchgeführt. Der 68881 ist somit (unabhängig von seiner vorherigen Verwendung) betriebsbereit.

Das Operandregister

Das Register wird verwendet, um Daten zwischen CPU und Coprozessor auszutauschen. Je nach Datenformat muß dieses 32 Bit-Register mehrfach gelesen bzw. beschrieben werden. Zur Übertragung einer Zahl im Double-Precision-Real-Format (64 Bit) sind zwei Zugriffe notwendig, wobei der höherwertige Anteil jeweils zuerst behandelt wird.

Das Responseregister

Um einen bestimmten Befehl auszuführen, muß ein Protokoll zwischen CPU und 68881 eingehalten werden. Teil dieses Protokolls (siehe unten) sind die Lesezugriffe auf dieses Register. Durch Auswertung des Registers erhält das Programm Informationen über den Zustand des 68881.

Folgende Codes sind vorgesehen:

$800, $801 Antwort auf Conditionbefehl (entspricht False, True)
$802 Idle, Coprozessor ist arbeitsbereit
$900, $4900 Busy, Coprozessor arbeitet, von der CPU werden keine weiteren Zugriffe erwartet
$1C31-$1D36,$5C0B,$5C30 Exception (z.B. Overflow; Division durch 0; Protocol-Violation: das Kommunikationsprotokoll wurde nicht eingehalten); in das Controlregister muß ein (beliebiger) Wert geschrieben werden, bevor ein weiterer Befehl aus geführt werden kann.
$810C, $A10C mehrere Register blockweise übertragen; darauf wird hier nicht genauer eingegangen.
$8900, $C900 Busy, Coprozessor arbeitet, benötigt aber von CPU noch Informationen bzw. kann mit der Abarbeitung des nächsten Befehls noch nicht beginnen; das Responseregister muß nochmals gelesen werden.
$9501-$9704, $D501-$D60C 68881 wartet auf Operanden, dieser muß über das Operandregister übertragen werden; anschließend muß das Responseregister erneut gelesen werden.
$B101-$B304 68881 möchte Operanden an die CPU übermitteln: dazu muß das Operandregister (eventuell mehrfach) gelesen werden; anschließend muß das Responseregister erneut gelesen werden.

Wenn nun die Bedienung des Coprozessors durch ein handgestricktes Assemblerprogramm erfolgt, kann auf die zeitaufwendige Auswertung des Responseregisters gewöhnlich verzichtet werden, weil (solange kein Fehler auftritt) die Reaktion des 68881 ohnedies vorhersehbar ist.

Eines muß dabei allerdings beachtet werden: solange der Coprozessor noch am vorigen Befehl arbeitet, kann er nicht mit dem nächsten Befehl beginnen. Wird nun das Responseregister (das in einem solchen Fall $8900 oder $C900 lautet) nicht berücksichtigt, kommt es zu einer sogenannten Protocol Violation. Aber auch das kann ohne Abfragen vermieden werden, wenn nach zeitaufwendigen Befehlen einige NOPs im Assemblerprogramm integriert werden, um die CPU zu bremsen.

Eine Ausnahme bilden die Wahrheitswerte nach einem Conditionbefehl - nach einem solchen Befehl muß das Responseregister natürlich explizit ausgewertet werden, um das Ergebnis der Abfrage zu erfahren (False oder True?).

Achtung: Es kann zwar gewöhnlich auf die Auswertung des Responseregisters verzichtet werden, das Register muß aber dennoch gelesen werden (auch der Befehl TST führt einen Lesezugriff aus), damit das Kommunikationsprotokoll (siehe unten) eingehalten wird.

Das Kommunikationsprotokoll

Aus den obigen Ausführungen geht hervor. daß die Kommunikation zwischen 68881 und CPU nach strengen Regeln verläuft. Diese Regeln sind in sogenannten Protokollen für verschiedene Typen von Befehlen festgehalten. Wenn man von diversen Spezialfunktionen zum Trap-Handling, Task-Wechsel... absieht, ergeben sich vier wichtige Befehlsgruppen:

1. Befehle ohne Operandentransport
2. Befehle, bei denen der Quelloperant an den 68881 übermittelt werden muß
3. Befehl, bei denen der Zieloperand (das Ergebnis) vom 68881 zur CPU übermittelt werden muß
4. Befehle zur Bedingungsabfrage

Im folgenden wird das Protokoll für diese vier Gruppen kurz beschrieben:

1. In das Commandregister wird der Befehlscode geschrieben, anschließend wird das Responseregister gelesen. Falls der Coprozessor noch mit dem vorigen Befehl beschäftigt ist ($8900, $C900), muß das Responseregister nochmals gelesen werden.

2. In das Commandregister wird der Befehlscode geschrieben, anschließend wird das Responseregister gelesen. Falls der Coprozessor noch mit dem vorigen Befehl beschäftigt ist ($8900, $C900), muß das Responseregister nochmals gelesen werden. Es ergibt sich nun die Aufforderung zum Operandentransport an den 68881 ($9501-$9704, $D501-$D60C), die Daten werden (je nach Format in mehreren Langwörtern, höherwertiger Anteil zuerst) in das Operandregister geschrieben. Anschließend muß das Responseregister erneut gelesen werden - es wird $802, $900 oder $4900 ergeben, wenn der Datentransport korrekt verlaufen ist.

3. Anfang wie oben, allerdings ergibt sich hier eine Aufforderung zum Operandentransport an die CPU ($B101-$B304). Der Operand wird aus dem Operandregister gelesen, anschließend muß das Responseregister nochmals gelesen werden (ergibt Idle, $802).

4. In das Conditionregister wird der Conditioncode geschrieben. Anschließend wird der resultierende Wahrheitswert ($800 oder $801) aus dem Responseregister gelesen.

Beispiele zur Befehlscodierung mit 68000

Es folgen nun Beispiele zu diesen vier Gruppen. Das Zustandekommen des Commandcodes wird unten im Detail beschrieben. Auf die Auswertung des Responseregisters wird bei Befehlen der Gruppen 1 bis 3 verzichtet.

1. FADD FP0,FP1

Das Fließkommaregister FP0 wird zu FP1 addiert.

Der Code $A2 ergibt sich aus dem Befehlscode für FADD ($22), dem Code für das Quellregister 0*$400 und dem Code für das Zielregister 1 *$80.

2. FADD.D (A0)+,FP1

Es soll also die bei (A0) beginnende Fließkommazahl im Double Precision-Format (daher die Kennung .D) zum 68881-Register FP1 addiert werden.

3. FMOVE.D FP3,(A0)+

Es soll das Fließkommaregister im Double Precision Format (‘.D’) in den Hauptspeicher beginnend bei (A0) übertragen werden.

4. FBGT label

Wenn die nach einem FCMP-Befehl gesetzten Flags signalisieren, daß der Zieloperand größer als der Quelloperand war, soll ein Sprung zum angegebenen Label erfolgen.

Der Commandcode

Der Commandcode ist jener Wert, der am Beginn des Protokolls für Befehle der Gruppen 1-3 in das Commandregister geschrieben wird. Er enthält den Erkennungscode des Befehles sowie weitere Informationen über die zu verarbeitenden Operanden (Register oder Zahlen aus dem CPU-Arbeitsspeicher). Es handelt sich dabei um den selben Wert, den ein 68020/68881 Assembler als zweites Wort (Command-Word) bei der Übersetzung eines FPU-Befehles generiert.

Command-Word für Befehle der Gruppe 1

Bit 0-6 (Extension-Field):
Befehlscode (z.B. $0,$20,$22,$23,$28,$38 für FMOVE, FDIV, FADD, FMUL, FSUB, FCMP)
Bit 7-9 (Destination-Register):
Nummer des Zielregisters
Bit 10-12 (Source-Register):
Nummer des Quellregisters
Bit 15,14,13: 0,0,0

Command-Word für Befehle der Gruppe 2

Bit 0-9: wie oben
Bit 10-12 (Source Format):
Formatcode(0,1,2,3,4,5.6 für Long Word Integer, Single Real,Extended Real. Packed Real, Word Integer, Double Real, Byte Integer)
Bit 15,14,13: 0,1,0

Das Sourceformat bestimmt, in welchem Zahlenformat ein Operand bei der Befehlsausführung an die FPU übertragen wird.

Command-Word für Befehle der Gruppe 3

Bit 0-9: wie oben
Bit 10-12 (Destination-Format): wie oben
Bit 15,14,13: 0,1,1

Der Conditioncode

Auch hier handelt es sich um das zweite Wort des im 68881 User Manual bei der Befehlsbeschreibung angegebenen Codes für 68020-Prozessoren (jetzt als ‘Condition-Word* bezeichnet). Es wird bei Befehlen der Gruppe 4 in das Conditionregister geschrieben.

Der Aufbau ist hier sehr einfach: Es handelt sich um einen 6 Bit-Code, der alle vorgesehenen Abfragen beinhaltet. Die wichtigsten Codes sind hier angegeben: $1,$E,$12,$13,$14,$15 für EQ, NE, GT, GE, LT, LE (Bedeutung wie bei 68000-Bedingungen).

Tabelle 1: Länge der fünf wichtigsten Interface-Register

Apfelmännchengrafiken

Der Algorithmus zur Berechnung der Apfelmännchengrafiken ist inzwischen so oft in Zeitschriftenartikeln und Büchern beschrieben worden, daß hier darauf verzichtet werden kann. In Listing 1 ist der Algorithmus als einfaches BASIC-Programm realisiert. Die Implementierung in Assembler verwendet die exakt gleichen Formeln und Variablennamen, weswegen das kleine Programm nützlich ist, um sich im (leider etwas längeren) Assemblerprogramm zu orientieren.

Um das Assemblerprogramm (Listing 2) möglichst kurz und zugleich flexibel für verschiedene Anwendungen zu halten, ist es nicht als eigenständiges Programm konzipiert. Vielmehr ist es als Unterprogramm in einer höheren Programmiersprache zu verwenden: Es berechnet jeweils eine Zeile der Apfelmännchengrafik, das aufrufende Programm muß sich um die Parameterübergabe und um die Ausgabe am Bildschirm kümmern. Das Assemblerprogramm ist somit vom Ausgabesystem (Bildschirm in allen Modi, Drucker...) unabhängig.

Das Programm beginnt mit einer Menge Konstanten Vereinbarungen: Diese stellen Teile des Commandcodes dar; durch ihre Kombination (Addition) können alle für das Programm notwendigen 68881-Befehle relativ einfach und übersichtlich zusammengesetzt werden. Für eigene Programme empfiehlt es sich, ähnliche Vereinbarungen zu treffen: Wenn arithmetische Befehle möglichst nur mit 68881-Registern ausgeführt werden, der Datentransport zwischen CPU und 68881 nur mit FMOVE durchgeführt wird, ist die Codegenerierung relativ einfach. Soll beispielsweise der Befehl

durchgeführt werden, muß hierzu ein Code (bestehend aus den Teilcodes für den Befehl ADD, für das Quellregister FP1 und das Zielregister FP2) ins Commandregister geschrieben werden:

Beim FMOVE-Befehl erfolgt eine Unterteilung in drei Verwendungsmöglichkeiten dieses Befehls: 68881-Register untereinander austauschen, 68881-Register vom CPU-Speicher lesen oder 68881 -Register an die CPU (bzw. deren Speicher) übertragen (wird im Programm nicht benötigt). Auch beim ADD-Befehl sind zwei Varianten vorgesehen.

Nach der Auflistung der Verwendung der einzelnen Register für Prozessor und Coprozessor beginnt das Programm mit einem Sprung über den Parameterblock. Dieser 44 Byte lange Block dient zur Kommunikation zwischen dem aufrufenden Programm und der Assemblerroutine. In den folgenden Zeilen wird der Parameterblock ausgelesen, die meisten Werte werden in Registern gespeichert, um eine möglichst hohe Verarbeitungsgeschwindigkeit zu erreichen.

Die Register A0-A4 enthalten die Adressen der einzelnen Interfaceregister; die Basisadresse des 68881 muß vom aufrufenden Programm angegeben werden - das Programm ist also unabhängig vom Ort der FPU. Das Ergebnis der Berechnungen wird in einem Integerfeld gespeichert - dessen Adressierung erfolgt über das Register A6. Das Register D3 enthält den Wert $801 (logisch True) zur Auswertung des Responseregisters nach Abfragen.

Anschließend werden die Register des 68881 mit Werten belegt. Diese müssen im Parameterblock im oben beschriebenen Double-Precision-Format vorliegen. Als Grenzwert wird die Zahl 4 bezeichnet, die als Vergleichswert bei der Abbruchbedingung in der innersten Schleife des Algorithmus’ notwendig ist (siehe Listing 1 bei EXIT IF).

Im folgenden werden die einzelnen Programmzeilen von Listing 1 in Assembler codiert. Dabei sind die eingefügten NOPs notwendig, weil der Coprozessor bei aufwendigeren Rechenoperationen (vor allem bei der Multiplikation) langsamer ist als die steuernde CPU. Das Timing des Programmes ist auf eine 8 MHz-CPU und einen 16 MHz-Coprozessor ausgelegt.

Schwierigkeiten gibt es nur, wenn entweder der Coprozessor langsamer oder aber die CPU schneller getaktet ist - in diesem Fall müssen zusätzliche NOPs eingefügt werden.

Der Zähler für die Rechentiefe läuft im Programm (im Gegensatz zu Listing 1) vom Maximalwert bis Null abwärts. Da im Ergebnisfeld aber die Anzahl der notwendigen Schleifendurchläufe gespeichert werden soll, wird (nach dem Label ABBRUCH) dieser Wert durch eine Subtraktion berechnet.

Der Vorgang wiederholt sich für alle Punkte der zu berechnenden Zeile (LOOP2). Abschließend wird das Responseregister nochmals ausgelesen und als letzter Wert im Ergebnisfeld gespeichert. Dieser Wert ist für die Grafik nicht von Bedeutung, er kann lediglich zu Testzwecken verwendet werden: Der Wert sollte $802 betragen, wenn die Kommunikation zwischen CPU und 68881 fehlerfrei funktioniert hat. $ 1DOD bedeutet, daß eine ‘Protocol Violation’ aufgetreten ist - dies würde auf Timing-Probleme deuten.

Tabelle 2

Das steuernde BASIC-Programm

Listing 3 zeigt die Einlagerung des Programmes in ein GFA BASIC 3.0-Programm. Wird der Befehl PSET durch den langsameren PLOT-Befehl ersetzt, läuft das Programm auch mit Version 2.0. Grundsätzlich kann aber jede höhere Programmiersprache die relativ einfachen Aufgaben der Kommunikation mit dem Assemblerprogramm und der Ausgabe am Bildschirm übernehmen.

Im BASIC-Programm wird zuerst die Auflösung des Bildes und der gewünschte Ausschnitt bestimmt. Ein Feld für die Rechenergebnisse der Assemblerroutine wird dimensioniert, in ein weiteres Feld wird das Assemblerprogramm aus den DATA-Zeilen gelesen.

Anschließend werden die Parameter für das Assemblerprogramm in den dafür vorgesehenen Speicherblock geschrieben. Die Adresse des ersten Elementes des Ergebnisfeldes wird um Zwei vergrößert übergeben, weil das Assemblerprogramm die Resultate als Word-Werte speichert.

Probleme machen dabei die Fließkommaparameter, die im Double-Precision-Format übergeben werden müssen. Besitzer von GFA-BASIC 3.0 können mit

einfach an eine beliebige Adresse eine Zahl in diesem Format schreiben. Wer diese Möglichkeiten nicht hat, kann stattdessen das Unterprogramm DOUBLE verwenden, das etwas langsamer ist. Das Unterprogramm zerlegt die übergebene Zahl zuerst in Exponent und Mantisse. Daraus werden zwei Integerwerte berechnet, die dann an die angegebene Adresse geschrieben werden. Hierbei muß darauf geachtet werden, daß der Zahlenbereich für Integerzahlen nicht überschritten wird - dieser beträgt -2147483648 bis +2147483647 und nicht 0 bis 4294967295. Werte über 2147483647 müssen daher (durch Subtraktion von 2^31) in negative Werte umgewandelt werden.

Nun zur FOR-NEXT Schleife, mit der das Assemblerprogramm für jede Grafikzeile einmal aufgerufen wird: Der Imaginärstartwert wird für jede Zeile berechnet und durch DOUBLE an das Assemblerprogramm übermittelt. Das Assemblerprogramm muß im Supervisormodus aufgerufen werden (CALL ist also nicht ausreichend), damit der Coprozessor ohne ‘Bomben’-Errors angesprochen werden kann - dies läßt sich sehr einfach mit der XBIOS-Funktion 38 erreichen.

Die Auswertung des Ergebnisfeldes und die Ausgabe am Bildschirm ist leicht verständlich - mit der EVEN-Funktion wird bei allen geradzahligen Resultaten ein Punkt gezeichnet. Natürlich bestehen unzählige andere Möglichkeiten zur Ausgabe - insbesondere in den Farbmodi.

Geschwindigkeit

Die Berechnung und Ausgabe des Basisapfelmännchens (Parameter wie im Programmlisting) dauert etwa 3.5 Minuten, wobei fast die Hälfte dieser Zeit für die Ausgabe benötigt wird. Werden Ausschnitte vergrößert, nimmt die Rechenzeit im Vergleich zur Ausgabezeit natürlich stark zu, so daß sich die Ausgabezeit kaum noch störend bemerkbar macht.

Noch eine Anmerkung zur Geschwindigkeit: Der 68881 besitzt einen Befehl, mit dem die Multiplikation mit halber Rechengenauigkeit, aber etwas höherer Geschwindigkeit durchgeführt werden kann. Auf den Einsatz dieses Befehls wurde verzichtet, weil der Geschwindigkeitsgewinn klein, der Verlust an Genauigkeit dagegen sehr groß wäre. Und erst die hohe Rechengenauigkeit ermöglicht starke Vergrößerungen von Ausschnitten des Apfelmännchens (Abbildung 1 kann mit einer Rechengenauigkeit von 8 Stellen nicht mehr berechnet werden).

Die Geschwindigkeit des Assemblerprogrammes wäre übrigens auch nicht viel höher, wenn statt des 68000 ein 68020 verwendet würde. Es kann dann zwar die Kommunikation mit dem 68881 etwas schneller (und vor allem viel einfacher) durchgeführt werden, die Rechengeschwindigkeit des 68881, der das Tempo hauptsächlich bestimmt, ändert sich aber nicht.

In Tabelle 2 sind einige Benchmarkresultate zu finden (Zeiten in Sekunden inklusive der Ausgabe am Bildschirm). Grundlage war eine Grafik mit 160*100 Punkten Auflösung, die Grenzen des Gebietes lauten -0.7476 bis -0.7452 für den Realteil, 0.0977 bis 0.0993 für den Imaginärteil, die Rechentiefe betrug 100. Zu beachten sind die unterschiedlichen Rechengenauigkeiten (angegeben in Dezimalstellen). Bei GFA-BASIC 2.0 und der 68881-Version stammen die Zeitangaben in Klammem aus compilierten Programmen. Bei OMIKRON.BASIC stand nur ein Interpreter zur Verfügung, die Messung wurde sowohl mit einfacher als auch mit doppelter Genauigkeit durchgeführt. Das verwendete Assemblerprogramm ohne 68881-Unterstützung stammt aus [2].

Quellen:

[1] MC68881 Floating Point Coprocesor User's Manual, Motorola 1985

[2] Kofler, Michael: Atari ST Grafikbuch, SYBEX 1987

Listing 1

Listing 2

Listing 3