Der 68010 und andere Übeltäter
Der Atari TT arbeitet mit einem 68030-Prozessor, der ST besitzt standardmäßig einen 68000. So weit, so gut. Im ST können jedoch auch andere Prozessoren der 68000-Familie ihren Dienst verrichten und für mehr Rechenleistung sorgen. Dieser Umstand kann eventuell zu Problemen führen.
Für den ST gibt es inzwischen diverse Prozessorkarten, die mit einem 68020 oder sogar mit einem 68030 bestückt sind. Auch ein 68010 kann in den ST eingesetzt werden. Die Erkennung des Prozessortyps ist für einige Programme durchaus von Bedeutung. Zwar erleichtert dies der sogenannte cookie jar [ 1 ], aber der wird von den alten, an den 68020 angepaßten TOS-Versionen, nicht immer unterstützt. In einigen Fällen empfiehlt es sich also, selber den Prozessortyp zu bestimmen. Schließlich soll ein unerwarteter Prozessor nicht die Ursache für einen Programmabsturz werden. Doch zunächst ein kleiner Überblick über die wichtigsten Nachfolger des MC68000 unter dem Aspekt der Geschwindigkeit.
Looping
Der 68010 ist pinkompatibel zum 68000, so daß beide Prozessoren relativ problemlos ausgetauscht werden können. (Eine Anpassung des Betriebssystems ist jedoch notwendig.) Der 68000 muß hierzu ausgelötet und durch seinen größeren Bruder ersetzt werden.
Die Befehlsverarbeitung wurde beim 68010 derart verbessert, daß ein Geschwindigkeitsvorteil von etwa 10% gegenüber einem 68000 verbucht werden kann. Dies liegt neben diversen Optimierungen bei den Ausführungszeiten einzelner Befehle auch am sogenannten „Loop-Modus“ des 68010-Prozessors, der für eine beschleunigte Abarbeitung kleiner Programmschleifen sorgt.
Beim Kopieren von Speicherbereichen (Listing 1) bearbeitet der Prozessor im wesentlichen nur zwei Befehle. Zunächst werden die Daten verschoben, anschließend die Bedingung für das Schleifenende abgefragt. Handelt es sich bei dieser Abfrage um einen Befehl des Typs dbxx und umfaßt die Schleife nur einen einzigen Befehl, so hält der 68010 diese beiden Befehle in einem speziellen Zwischenspeicher (vergleichbar mit einem kleinen Cache) und braucht diese nicht bei jedem Schleifendurchlauf erneut zu decodieren. Dies führt zu einer besonders schnellen Befehlsbearbeitung innerhalb kurzer Schleifen.
Das „Superding"
So jedenfalls wurde der MC68020 noch 1984 bezeichnet [2]. Heute kann man über diese Bezeichnung eher schmunzeln, hat sich doch auf dem Gebiet der Mikroprozessoren inzwischen einiges getan. Aber dennoch, die Entwicklung „echter“ 32-Bit-Prozessoren mit 32-Bit-Daten- und Adreßbus war ein wichtiger Schritt.
Verglichen mit dem 68010 hat der 68020 diverse neue Adressierungsarten und einige zusätzliche Befehle. Der MC68020 arbeitet standardmäßig mit einer höheren Taktfrequenz als seine Vorgänger, was sich in einer deutlich größeren Geschwindigkeit niederschlägt. Erstmals finden wir bei MO-TOROLA-Prozessoren einen Befehls-Cache mit einer Größe von 256 Bytes. Die zuletzt bearbeiteten Befehls-Bytes befinden sich stets innerhalb des
Prozessors, so daß auch größere, sich wiederholende Programmteile in kürzester Zeit abgearbeitet werden können. Der 68020 ist in der Lage, mit anderen Prozessoren (z.B. Fließkomma-Coprozessoren) zusammenzuarbeiten.
Der 68030
Atari verwendet diesen Prozessor im Atari TT. Neben einem Befehls- ist beim MC68030 auch ein Daten-Cache vorhanden, was zu einem weiteren Geschwindigkeitszuwachs führt. Auf dem Chip ist eine PMMU (Paged Memory Management Unit) integriert, die es erleichtert, Multitasking-sowie Multiuser-Systeme mit virtueller Speicherverwaltung zu verwirklichen. Dies ist besonders für Betriebssysteme wie UNIX von Bedeutung.
Paradepferd
Der neueste Prozessor der 68000-Familie ist der MC68040, der noch nicht in größeren Stückzahlen erhältlich ist. Bei den ersten Rechnern, die standardmäßig mit diesem Prozessor ausgerüstet werden, dürfte es sich um die neue NeXT-Generation handeln.
Besonders interessant ist die Tatsache, daß bei 68040-Systemen keine externen Fließkomma-Coprozessoren mehr benötigt werden, da der neue Prozessor einen gegenüber dem 68030 um Fließkomma-Operationen erweiterten Befehlssatz besitzt. Außerdem arbeitet der 68040 intern mit der doppelten der außen angelegten Taktfrequenz, so daß er mit Abstand das schnellste Mitglied der 68000-Familie darstellt.
Übrigens: Einen 68040-Prozessor kann man in Atari-Computern (noch) nicht antreffen.
Erkennung des Prozessortyps
Wichtige Hardware-Merkmale eines Rechners können von einem Programm anhand der Daten des cookie jars ermittelt werden [2]. Hier werden sowohl Angaben über den Rechner (ST, TT) als auch über den Prozessortyp abgelegt. Der cookie jar existiert allerdings erst ab TOS 1.06, das sich im 1040 STE befindet. Ältere TOS-Versionen stellen keine Angaben über den verwendeten Prozessor zur Verfügung. Hier muß man davon ausgehen, daß ein 68000-Prozessor vorhanden ist. Dieses Vorgehen ist in der Regel auch korrekt. Probleme kann es jedoch dann geben, wenn man einen ST mit einer Prozessorkarte betreibt, die mit einem anderen Prozessor als dem 68000 bestückt ist. Für solche Karten wird ein modifiziertes TOS benötigt. Legt eine solche TOS-Version keinen eigenen cookie jar an, ist es einem Programm nicht ohne weiteres möglich, eine Entscheidung über den Prozessortyp zu fällen.
Eine Differenzierung zwischen den einzelnen Prozessoren ist jedoch dann notwendig, wenn im Verlauf einer Exception auf den Interrupt-Stack zugegriffen werden soll. Im Gegensatz zum 68000 legen alle anderen Prozessoren der 68000-Familie nach einer Exception je nach deren Typ unterschiedlich viele Bytes auf den Stack. Ist nun keine Information über den Prozessor greifbar, kann dies beim Stack-Zugriff zu Fehlern führen.
Who is who?
Wie stellt man nun fest, welcher Prozessor seinen Dienst verrichtet? Um dieses Problem zu lösen, macht man sich Unterschiede in den Befehlssätzen der einzelnen Prozessoren zunutze. Listing 2 stellt ein Programmfragment dar, das den Prozessortyp ermittelt und in leicht modifizierter Form in eigene Programme eingebaut werden kann.
Zunächst wird geprüft, ob ein 68000-Prozessor vorliegt. Dazu setzt man einen Befehl des Typs MOVE SR,Dx ein. Hierdurch wird beim 68000 das komplette Statuswort (also auch das System-Byte) in ein Datenregister übertragen. Nur beim MC68000 kann dieser Befehl im User-Modus ausgeführt werden. Bei allen anderen Prozessoren sind Zugriffe auf das System-Byte des Statusregisters ausschließlich im Supervisor-Modus erlaubt, so daß obiger Befehl im User-Modus zu einer Privilegverletzungs-Exception führt. Tritt keine solche Exception auf, ist der Prozessor als 68000 identifiziert. Die hier vorgestellte Methode wird übrigens auch bei der Textverarbeitung TEMPUS WORD eingesetzt.
Maskenball
Im nächsten Schritt wird getestet, ob wir einen 68010 vor uns haben. Die hier verwendete Methode stammt aus [3] und ist besonders interessant. 68020 und 68030 verfügen über diverse neue Adressierungsarten, von denen eine die indirekte Adressierung mit Index darstellt, die folgende Syntax besitzt:
(xxx,An,Xn*SCALE)
.xxx stellt hierbei ein 8-Bit-Displacement dar, bei An handelt es sich um ein Adreßregister. Xn kann sowohl ein Adreß- als auch ein Datenregister sein. Dieses Register wird im Zuge der Adreßberechnung mit dem Faktor SCALE multipliziert, der die Werte 1, 2 oder 4 annehmen kann. Diese Adressierung ist somit besonders bei Zugriffen auf Tabellen nützlich, da je nach Skalierungsfaktor auf Bytes, Worte oder Langworte zugegriffen werden kann, ohne daß der im Register Xn enthaltene Index zerstört wird.
Beim 68010 (übrigens auch beim 68000) führen Befehle des obigen Typs, die nicht zum Befehlssatz dieses Prozessors gehören, nicht zu einer Exception. (Dieses Verhalten könnte durch einen Maskenfehler bedingt sein.) Vielmehr wird der Skalierungsfaktor ignoriert. Im Beispiel-Listing wird D0=1 als Index beim Lesezugriff auf eine Tabelle verwendet. Wird ein Wert ungleich Null gelesen, verrichtet ein 68010 seine Arbeit. In diesem Fall wurde die Skalierung nämlich nicht berücksichtigt. Eine 0 wird dagegen nur dann zurückgeliefert, wenn ein 68020/30 vorliegt.
Der letzte Schritt
Nun gilt es nur noch, zwischen 68020 und 68030 zu unterscheiden. Auch hier gibt es Differenzen im Befehlssatz. Man darf nun jedoch nicht einfach irgendeinen der zusätzlichen PMMU-Befehle des 68030 zur Identifizierung des Prozessors heranziehen. Es könnte ja sein, daß sich eine externe PMMU des Typs 68851 im System befindet, so daß diese Befehle auch dann erlaubt sind, wenn nur ein 68020 vorhanden ist.
Selbst bei Rechnern mit externer PMMU, also beim 68020 kombiniert mit 68851, ergeben sich gegenüber dem 68030 Unterschiede bei den PMMU-Befehlen. So ist der Befehl PMOVEED (eine Abart von PMOVE) nur beim 68030, nicht jedoch bei der PMMU 68851 implementiert. Hier führt ein entsprechender Opcode zu einer Exception über den LINE-F-Vektor. Wird der Befehl jedoch ausgeführt, ist ein 68030 im System vorhanden.
Am Ende der vorgestellten Routine enthält das Register D7 eine Angabe über den Prozessortyp ($00, $10, $20, $30). Hieraus kann das Hauptprogramm nun seine Schlüsse ziehen.
Nicht nur Vorteile
Nun noch zu einem Hinweis für Programmierer, die Programme bevorzugt auf dem TT entwickeln. Eine größere Flexibilität der Prozessoren 68020 und 68030 zeigt sich bei Zugriffen auf Worte oder Langworte, die auf ungeraden Adressen liegen. Hier beschweren sich 68000 und 68010 mit einem Adreßfehler, so daß solche Zugriffe nicht möglich sind. 68020 und 68030 sehen die Sache nicht so eng. Soll ein Wort an einer ungeraden Speicheradresse manipuliert werden, ist das nun erlaubt. Zwar dauert ein solcher Zugriff doppelt so lange wie bei Datenworten auf geraden Adressen, aber es gibt keinen Adreßfehler. Dies mag in manchen Fällen durchaus praktisch sein. Probleme gibt es jedoch dann, wenn dieser Zugriff ungewollt durch einen Programmfehler stattfindet.
Hierzu enthält Listing 3 ein Beispiel. Von den beiden Variablen byte1 und byte2 wird byte1 mit dem even-Befehl des Assemblers an einer geraden Adressen abgelegt, so daß sich byte2 zwangsweise an einer ungeraden Adresse befindet. Im Programmfragment wird nun irrtümlicherweise byte2 mittels clr.w als Wort angesprochen, statt daß clr.b verwendet wird. Dieser Zugriff wird beim 68000/10 einen Adreßfehler hervorrufen, so daß man als Programmierer gewarnt ist.
Beim 68020/30 führt dieser Befehl dazu, daß neben byte2 auch byte3 gelöscht wird. Da die ungewollte Manipulation von byte3 nicht direkt zu einem Folgefehler führen muß, hat der Befehl clr.w zunächst einmal seinen Zweck erfüllt. Im weiteren Programm verlauf kann der fehlerhafte Inhalt von byte3 nun jedoch zu Fehlern führen, deren Ursache nur schwer zu finden sein kann.
Insbesondere Assembler-Programmierer dürften von dieser Fehlerquelle betroffen sein. Aber auch bei einer Hochsprache wie C kann man durch falsche Benutzung eines Pointers in die Falle gehen.
Findet die Entwicklung eines Programms für ST und TT ausschließlich auf einem Atari TT statt, ist nicht auszuschließen, daß ein fehlerhafter Zugriff dieser Art überhaupt nicht entdeckt wird. Ein jedes Programm sollte deshalb unbedingt auch auf einem ST getestet werden.
Literatur:
[1] Rolf Kotzian, „Das Cookie-Jar-Prinzip“, ST-Computer 12/90
[2] Werner Hilf, Anton Nausch, „M68000 Familie. Teil 2 - Anwendung und 68000-Bausteine", te-wi Verlag
[3] Steve Williams, „68030 Assembly Language Reference", Addison-Wesley Publishing Company Inc.
verschiebe:
lea quelle,a0 ;Pointer auf
lea ziel,a1 ;Quelle und Ziel
move #anzahl-1,d0 ;so viele Worte
;werden verschoben
schleife:move (a0)+,(a1)+ ;Worte verschieben
dbra d0,schleife ;auf Schleifenende prüfen
rts
Listing 1: Verschieben eines Speicherblocks im Loop-Modus des 68010
*************************************
* GET_CPU *
* *
* Identifizierung des Prozessortyps *
* (c) MAXON Computer *
* Januar 1991 by Uwe Seimet *
*************************************
SETEXC = 5
BIOS = 13
SUPEXEC = 38
XBIOS = 14
text
*Dieses Unterprogramm liefert in D7 Angaben
*über den Prozessor ($00, $10, $20, $30)
get_cpu:
pea newpriv(pc) ;neuer Vektor
move #8,- (sp) ;für Privileg-
move #SETEXC,-(sp) ;Verletzung
trap #BIOS
addq.l #8,sp
move.l d0,d5
*auf 68000-prüfen
move sr,d0 ;Exception,
;falls kein 68000
moveq #$00,d7 ;Flag für 68000
bra.b exit
*auf 68010 prüfen
newpriv:
or #$0300,sr ;zurück in
;Usermodus
moveq #$10,d7 ;Flag für 68010
moveq #1,d0
lea table,a0
tst.b (0,a0,d0*4)
bne.b exit ;68010 erkannt-
*auf 68020 prüfen
pea testmmu(pc)
move #SUPEXEC,-(sp)
trap #XBIOS ;auf PMMU testen
addq.l #6,sp
move mmureg,d7 ;Prozessortyp
exit: move.l d5,-(sp) ;alten Vektor
move #8,-(sp) ;wiederherstellen
move #SETEXC,-(sp)
trap #BIOS
addq.l #8,sp
*D7 enthält nun den Prozessortyp
*($00, $10, $20, $30) im low word
rts
*auf externe PMMU oder 68030 testen
testmmu:
move.l $02c,d0 ;LINEF-Vektor
move.l #1inef,$02c
moveq #$20,d7 ;Flag für 68020
pmove crp,mmureg ;Exception,
;falls keine PMMU
;=> 68020
pmovefd mmureg,crp ;Exception,
;falls kein 68030
;sondern PMMU
;=> 68020
*sonst 68030
moveq #$30,d7
linef:move.l d0,$02c ;alter Vektor
move d7,mmureg ;Prozessor merken
rts
*Hilfstabelle
table:dc.b 0,0,0,1,0,0,0,0
bss
mmureg: ds.l 2
Listing 2
*Demonstration der Folgen eines Wortzugriffs
*auf eine ungerade Adresse, obwohl ein Bytezugriff
*beabsichtigt war (clr.w statt clr.b)
.
.
.
clr.w byte2 ;Wort- statt
. ;Bytezugriff
. ;(führt beim 68000
. ;zum Adreßfehler)
bss
even
byte1: ds.b 1 ;an gerader Adresse
byte2: ds.b 1 ;an ungerader Adresse
byte3: ds.b 1 ;wird irrtümlich gelöscht, was
;zu Folgefehlern führen kann
Listing 3: Folgen eines falschen Wortzugriffs
Uwe Seimet