THE NEXT STEP 68040 Tendenzen
Was wäre, wenn es eines Tages einen ST/TT-kompatiblen Rechner mit 68040-Prozessor geben würde? Auf der diesjährigen Atari-Messe in Düsseldorf wurde ein solches Gerät zwar nicht vorgestellt, aber die nächste Messe kommt bestimmt. Wenn es dann einmal soweit ist, stellt sich wieder die altbekannte Frage nach der Kompatibilität.
Regelmäßige Leser dieser Zeitschrift erinnern sich vielleicht noch: Eine ähnliche Thematik wurde bereit vor etwa einem Jahr behandelt [ 1 ]. Damals ging es jedoch um die ST-Kompatibilität eines zum damaligen Zeitpunkt bereits erhältlichen Rechners, nämlich um die des TT.
Wenn es nun darum geht, sich Gedanken über die Kompatibilität eines Computers zu machen, über den momentan, wenn überhaupt, nur Mitarbeiter der Firma Atari etwas wissen dürften, so mag dies ein wenig ungewöhnlich erscheinen. Wie soll man Aussagen über ein Gerät machen können, das niemand kennt und von dem man nicht weiß, ob und wann es auf den Markt kommen wird?
Nun, an dieser Stelle soll es nicht um die Eigenschaften eines neuen Rechners in seiner Gesamtheit gehen, sondern um das Herzstück eines jeden Computers: den Prozessor. Einem zukünftigen ST/TT-kompatiblen Gerät darf man unterstellen, daß es mit einem 68040-Prozessor ausgestattet sein wird. Und über diesen Baustein gibt es nicht nur bereits Unterlagen, sondern auch einen Rechner, der mit diesem Prozessor arbeitet. (Hierbei handelt es sich um den NeXT.)
Prozessorvergleich
Reduzieren wir die Fragestellung also auf den Kernpunkt: Kann der Einsatz eines 68040-Prozessors Inkompatibilitäten zu den bisherigen Atari-Computern, insbesondere zum TT, zur Folge haben? Angesichts der Tatsache, daß das Ende dieses Artikels noch nicht erreicht ist, schließen Sie richtig, daß es in der Tat Unterschiede zwischen den Prozessoren 68030 und 68040 gibt, die Auswirkungen auf die Software haben können.
Ein Vergleich beider Prozessoren verschafft Klarheit. Dabei gilt es, nicht nur den 68030 als Grundlage heranzuziehen, sondern auch den Fließkomma-Coprozessor 68882, mit dem alle TTs standardmäßig ausgestattet sind. (Hoffen wir, daß das auch in Zukunft so bleiben wird.) Wem nicht klar ist, warum es hier nicht alleine um 68030 und 68040, sondern auch um den Coprozessor geht, den dürfte interessieren, daß der 68040 keinen Fließkommaprozessor mehr benötigt, sondern selber die entsprechenden Zahlenformate bearbeiten kann. Dabei gibt es jedoch gewisse Einschränkungen zu beachten.
Fließkomma-Arithmetik
Dieser Abschnitt könnte auch eine andere Überschrift tragen, etwa „Fehlende Befehle“. Denn der 68040 erweist sich in diesem Punkt auf den ersten Blick als nicht so leistungsstark wie das Gespann 68030/68882. Betrachtet man den 68040 als eine Verschmelzung dieser beiden Prozessoren, wie wir es tun, so fehlt dem 68040 ein Großteil der Fließkommabefehle aus dem 68882-Befehlssatz. Außerdem ist der 68040 nicht in der Lage, den Datentyp Packed Decimal direkt zu verarbeiten.
Es ist eigentlich recht ungewöhnlich, aber nicht das erste Mal, daß ein neuer Prozessor der 68000-Familie nicht alle Befehle seiner Vorgänger unterstützt. Bereits bei der Entwicklung des 68030 wurden zwei Befehle aus dem Befehlssatz des 68020 nicht implementiert. Dabei handelte es sich um CALLM und RETM. Diese Befehle erlaubten in Verbindung mit der externen PMMU 68851 das Aufrufen von Unterprogrammen (Modulen) unter Verwendung eines speziellen Speicherschutzmechanismus’. Diese Möglichkeit gibt es seit dem 68030 nicht mehr.
Daß Motorola einen gewissen Teil der Fließkommaunterstützung beim 68040 nicht implementiert hat, dürfte in erster Linie damit Zusammenhängen, daß der Platz auf dem Chip die Realisierung aller Befehle des 68882 nicht zuließ. So werden insbesondere die Winkel- und Exponentialfunktionen vom 68040 nicht mehr unterstützt. Die komplexeste Funktion, die noch direkt erreichbar ist, dürfte wohl die Wurzelfunktion sein. Sind beim 68882 noch 50 verschiedene Operationen fest verdrahtet, so wurde diese Zahl beim 68040 auf 20 reduziert. Natürlich darf die „Abmagerungskur“, die die Fließkommafunktionen mitgemacht haben, nicht zu Inkompatibijitäten mit den Prozessoren 68881/ 68882 führen. Daher besteht die Möglichkeit, fehlende Fließkommaoperationen durch geeignete Software zu emulieren. Motorola stellt hierzu ein Programmpaket zur Verfügung. Optimal läßt sich der 68040 für Fließkommaberechnungen jedoch nur dann nutzen, wenn Code verwendet wird, der auf die eingeschränkten Möglichkeit dieses Prozessors abgestimmt ist.
Es ist übrigens nicht möglich, eine Software-Emulation zu umgehen, indem man dem 68040 einen 68882 zur Seite stellt. Zwar liegt dieser Gedanke nahe, aber der 68040 ist nicht in der Lage, mit einem Fließkomma-Coprozessor zusammenzuarbeiten. Dies mag zunächst unverständlich erscheinen, denn man könnte meinen, daß mit einem Verzicht auf den Coprozessor und den Zwang zur software-unterstützten Emulation einiger Fließkommabefehle ein Geschwindigkeitsverlust gegenüber dem hypothetischen Gespann 68040/68882 verbunden sein müßte. Dem ist jedoch nicht so. Rechnungen zeigen, daß der 68040 mit der entsprechenden Software Fließkommaoperationen deutlich schneller durchführt, als dies ein 68882 könnte. Somit dürfte die Welt also wieder in Ordnung sein. (Auch wenn besagte Rechnungen von Motorola stammen, dürfen wir diesen Angaben wohl dennoch trauen.)
Die PMMU
Bei diesem Baustein handelt es sich um einen weiteren wichtigen Bestandteil des 68040. Bereits der 68030 ist mit einer PMMU (Paged Memory Management Unit) ausgerüstet. Von dieser machen bereits diverse Programme für den TT Gebrauch, weshalb in vorausgegangenen Ausgaben der ST-Computer des öfteren auf Eigenschaften der PMMU eingegangen wurde. Deshalb an dieser Stelle nur soviel: Die MMU erlaubt es, Speicherbereiche an beliebigen Stellen innerhalb des Adreßraums einzublenden und diese mit Zugriffsbeschränkungen zu versehen. Diese Eigenschaft ist dann von besonderer Bedeutung, wenn innerhalb einer Multiuser-Umgebung gearbeitet wird oder das Prinzip der virtuellen Speicherverwaltung zur Anwendung kommt [2].
Muß man sich beim 68030 noch mit einer einzigen PMMU zufriedengeben, so gibt es beim 68040 gleich zwei davon. Es existiert eine MMU für die Übersetzung von Daten- und eine für die Übersetzung von Befehlszugriffen. Zwei MMUs bieten den Vorteil, daß Befehls- und Datenzugriffe simultan übersetzt werden können. Hier zeigt sich eine der besonderen Eigenschaften des 68040, nämlich die, daß dieser Prozessor besonders viele Operationen gleichzeitig ausführen kann.
Wirft man einen Blick auf die Leistungsmerkmale der beiden 68040-PMMUs, so dürfte man eine gewisse Enttäuschung erleben. Läßt sich der Speicher beim 68030 noch in Speicherseiten von 256 Bytes bis 32 kByte einteilen (32 kByte ist die Standardgröße beim TT), so sind beim 68040 lediglich Seiten von 4 oder 8 kByte zugelassen. Systemnahe Software für den TT, die auf eine Seitengröße von 32 kByte fixiert ist, wird auf dem 68040 also mit Sicherheit Schiffbruch erleiden.
Ihre Software läuft auch mit einer anderen Seitengröße? Dann freuen Sie sich nun vielleicht zu früh. Denn es gibt noch weitere einschneidende Änderungen, die die Adreßübersetzung betreffen. Ließen sich die Deskriptortabellen, die die Umsetzung des logischen in den physikalischen Adreßraum definieren, beim 68030 noch in 4 Ebenen indizieren, so werden in Zukunft nur noch 3 Ebenen zur Verfügung stehen. Diese können zudem nicht mehr beliebig indiziert werden. Das Translation-Control-Register TC des 68030 stellt die Felder TIA, TIB, TIC und TID zur Verfügung, um einen flexiblen Aufbau der Deskriptoren zu ermöglichen. Für den 68040 dagegen sind TIA und TIB auf jeweils 7 Bit fixiert. TIC umfaßt je nach Seitengröße 5 oder 6 Bit. Eine weitere Änderung, die das TC-Register betrifft: Dieses wird nicht mehr wie beim 68030 über einen PMOVE-Befehl angesprochen, sondern über MOVEC.
Was schließlich die Tabellen- und Seitendeskriptoren betrifft, die die Umsetzung der logischen in physikalische Adressen festlegen, so sind beim 68040 nur noch Deskriptoren mit einer Länge von 32 Bit erlaubt. Sogenannte „Early-Termination“-Deskriptoren sind nicht mehr zulässig. Für die praktische Anwendung heißt dies, daß sich im Prinzip die komplette Baumstruktur der Deskriptortabellen im Speicher befinden müßte. Um dies zu umgehen, bleibt lediglich die Möglichkeit, ungültige Deskriptoren statt Early-Termination-Deskriptoren einzusetzen. Dies erfordert im Falle eines Busfehlers allerdings zusätzliche Aktionen, die beim 68030 entfallen. Fast hätte ich es vergessen: Trotz dieser Hiobsbotschaften gibt es noch eine Verbesserung bei den PMMUs des 68040. Jede kann in ihrem ATC (Address Translation Cache) nämlich bis zu 64 Einträge halten, beim 68030 waren es lediglich 22. Ein größerer ATC ist beim 68040 recht wichtig, da die Deskriptortabellen aufgrund der wenig flexiblen MMU-Architektur in der Regel größer ausfallen werden als beim 68030. Und noch eine zusätzliche Erweiterung: Der 68040 stellt vier Transparent-Translation-Register zur Verfügung, wovon jeweils zwei der Daten-und zwei der Befehls-MMU zugeordnet sind.
Exception-Behandlung
Systemnahe Programme (insbesondere Debugger), die für den Atari ST geschrieben waren, stürzten auf dem TT beim Auftreten einer Exception häufig ab. Die Ursache hierfür war im gegenüber dem 68000-Prozessor geänderten Stack-Format des 68030 zu suchen. Beim 68040 wurde der Stack-Aufbau wiederum geändert, dieses Mal allerdings nur in einem wesentlichen Punkt. Dabei geht es um die Daten, die bei einem Busfehler auf dem Stack abgelegt werden und in erster Linie für die virtuelle Speicherverwaltung von Bedeutung sind.
Der 68030 erlaubt es, einen durch einen Busfehler unterbrochenen Befehl fortzusetzen. (Voraussetzung dafür ist natürlich, daß die Ursache für den Fehler innerhalb der Exception-Routine beseitigt wird.) Im Gegensatz dazu arbeitet der 68040 mit einem völlig anderen Mechanismus. Bei diesem Prozessor wird der unterbrochene Befehl nicht fortgeführt, sondern wiederholt. Auf den ersten Blick mag dies keinen großen Unterschied machen, kann sich aber sehr wohl auf Programme aus wirken, die in die Busfehlerbehandlung eingreifen. Der Wiederholungsmechanismus hat zur Folge, daß der MC68040 beim Auftreten eines Busfehlers weniger Informationen auf dem Stack ablegen muß als der 68030, was zu einer beschleunigten Exception-Bearbeitung führt. Darüber hinaus haben diese Daten auf beiden Prozessoren eine völlig andere Bedeutung.
Der Cache
Um den Datendurchsatz zu beschleunigen, ist der 68030 des TT mit einem Befehls- und einem Daten-Cache ausgestattet. Beide Caches umfassen jeweils 256 Bytes. Der Daten-Cache dient als schneller Zwischenspeicher für die zuletzt verwendeten Datenwörter, der Befehls-Cache enthält die zuletzt ausgeführten Befehle. Insbesondere Schleifen, die komplett im Prozessor-Cache Platz finden, werden bei aktiviertem Cache mit erhöhter Geschwindigkeit ausgeführt, da nur wenige oder gar keine Buszugriffe erfolgen müssen. Die große Bedeutung, die der Cache für die Leistung des Prozessors hat, läßt sich beim TT leicht dadurch überprüfen, daß man den Cache über den Desktop abschaltet. Die Rechenleistung sinkt sofort spürbar.
Die Caches des 68040 haben eine Größe von jeweils 4096 Bytes und können im „Write Through“- oder „Copy Back“-Modus betrieben werden. Die erstgenannte Betriebsart entspricht der des 68030. „Copy Back“ bedeutet, daß bei Schreibzugriffen zunächst ausschließlich der interne Prozessor-Cache beeinflußt wird, die Daten im Speicher jedoch nur bei Bedarf verändert werden. Dies kann ungewollte Effekte mit sich bringen. Modifiziert sich nämlich ein Programm während der Laufzeit, so resultiert dies lediglich in einer Manipulation des Daten-Caches. Daten, die sich bereits im Befehls-Cache befinden, werden nicht verändert. Im Klartext: Der Cache enthält in diesem Fall noch die alten Befehle, die Modifikation blieb also ohne Wirkung oder wurde nur teilweise durchgeführt. Eine solche Situation ist äußerst absturzträchtig, falls die modifizierte Stelle erneut durchlaufen wird, ohne daß zwischenzeitlich die entsprechenden Cache-Einträge durch die aktuellen Daten ersetzt wurden. Aus diesem Grund ist es eigentlich nicht erlaubt, daß sich Programme selbst modifizieren. Die Daten, die sich im TEXT-Segment eines Programms befinden, sollten während des gesamten Programmverlaufs unverändert bleiben. Läßt sich selbstmodifizierender Code dennoch nicht vermeiden, muß der Cache nach einer solchen Operation unbedingt gelöscht werden.
Neue Befehle
Zwar besitzt auch der 68040 ein CACR, aber dieses Register ist nur noch dafür zuständig, Befehls- und Daten-Cache ein- und auszuschalten. Sonstige Cache-Manipulationen verlaufen nicht mehr über die für den 68030 notwendigen Bit-Manipulationen des Cache-Control-Registers, sondern mit Hilfe einiger neuer Befehle für die Cache-Verwaltung.
Allgemein läßt sich festhalten, daß der Befehlssatz des 68040 nur kleine Erweiterungen gegenüber dem Gespann 68030/68882 aufweisen kann. Die Neuerungen beziehen sich in erster Linie auf die Cache-Steuerung. Es handelt sich um sechs Befehle des Typs CINV bzw. CPUSH, mit denen Cache-Einträge gelöscht werden können. Es ist nicht mehr möglich, den Cache-Inhalt einzufrieren, was beim 68030 noch unterstützt wurde. Programme, die von dieser Eigenschaft Gebrauch machen, werden auf dem 68040 dennoch keine Schwierigkeiten machen. Werden im CACR Bits manipuliert, die nicht mehr unterstützt werden, führt dies nicht zu einem Fehler.
Von Cache-Befehlen abgesehen, findet man beim 68040 nur noch einen neuen Befehl, nämlich MOVE 16. Anhand des Mnemonics läßt sich schon fast erraten, was es damit auf sich hat: Dieser Befehl erlaubt es, 16 Bytes auf einen Schlag zu verschieben. Sein Einsatzbereich ist jedoch recht beschränkt, da sich der Beginn der Daten auf einer Cacheline (eine durch 16 teilbare Adresse) befinden muß.
RISC-Struktur
Nachdem bisher lediglich die Rede von Leistungsmerkmalen war, die 68030/68882 und 68040 im großen und ganzen gemeinsam haben, wenden wir uns nun noch den wichtigsten Eigenschaften des 68040 zu, die gegenüber den restlichen Prozessoren der 68000-Familie neu hinzugekommen sind. Auf einige wichtige Neuerungen sind wir ja bereits gestoßen. Hierzu zählen zwei PMMUs, die größeren Caches und ein leicht erweiterter Befehlssatz. Doch an anderen Stellen zeigt sich die Überlegenheit des 68040 gegenüber dem 68030 besonders deutlich.
Allgemein kann man davon ausgehen, daß mit der Weiterentwicklung der Chip-Technologie neben einer höheren Integrationsdichte auch der Datendurchsatz steigt. So ist es auch beim 68040. Zunächst einmal arbeitet dieser Prozessor intern mit dem Doppelten der externen Taktfrequenz, die für das restliche System gilt. So kann man, sofern keine Buszugriffe nötig sind, von einer Geschwindigkeitsverdoppelung bei internen Operationen ausgehen. Durch weitere Optimierung des Mikrocodes wurde es erreicht, die häufigsten Befehle in einem einzigen Taktzyklus zu verarbeiten.
Die Eigenschaft, für jeden Befehl nur einen Zyklus zu benötigen, wird insbesondere bei den sogenannten „RISC-Prozessoren“ (Reduced Instruction Set) verwirklicht. Der Befehlssatz dieser Prozessoren ist nicht so umfangreich wie bei CISC-Prozessoren (Complex Instruction Set), zu denen auch die Prozessoren der 680x0-und 80x86-Familie zählen. Dafür sind alle Befehle jedoch fest verdrahtet, was eine besonders schnelle Befehlsbearbeitung garantiert. Der 68040 kommt dem RISC-Konzept insofern recht nahe, daß er viele Befehle in einem Zyklus ausführt. Zwar macht dies aus dem 68040 noch lange keinen echten RISC-Prozessor, aber dennoch spricht Motorola gerne davon, daß der 68040 eine RISC-Struktur besäße. Gleiches gilt übrigens für den 80486 von Intel, der in IBM-kompatiblen Geräten seine Anwendung findet.
Soweit ein Überblick über die wichtigsten der neuen Leistungsmerkmale des 68040. Daß es nicht bei den angeführten Beispielen geblieben ist, zeigt die Literatur zu diesem Prozessor [3],[4]. Wer TT-spezifische Software schreibt, sollte bereits jetzt einen Blick insbesondere in [4] werfen, um nicht irgendwann eine unangenehme Überaschung zu erleben.
Die Kompatibilitätsfrage
Wie wir gesehen haben, ist der 68040 in einigen Punkten nicht unbedingt kompatibel zum 68030. Läßt sich das mit der Produktpolitik von Motorola vereinbaren, die eine Abwärtskompatibilität aller Prozessoren der 68000-Familie propagiert? Dies mag wie eine rhetorische Frage klingen, die die Antwort „Nein“ impliziert. Nehmen wir Motorola jedoch beim Wort. Es ist stets die Rede davon, daß der Objectcode aller Prozessoren auf der User-Ebene abwärtskompatibel ist. So gesehen kann man dem 68040 durchaus bescheinigen, daß er kompatibel zu den Vorgängermodellen ist. Überlegt man, welche Programme von den Änderungen in der Prozessorarchitektur betroffen sein könnten, so wird es sich hierbei ausschließlich um systemnahe Programme handeln. Und selbst hier dürften nur dann Probleme auftreten, wenn es um die Nutzung des Caches oder der PMMU geht. Solange ein Programm nur Kleinigkeiten im Supervisor-Modus erledigt, sind auch hier keine Inkompatibilitäten zu erwarten. Im Überblick läßt sich über 68030/68882 und 68040 sagen, daß es weniger neue Eigenschaften des 68040 sind, die auf Systemebene zu Inkompatibilitäten führen können, als vielmehr Möglichkeiten, die vom 68040 nicht mehr unterstützt werden.
Also auf der User-Ebene alles eitel Sonnenschein? Kann man davon ausgehen, daß zukünftige Atari-Computer den größten Teil des bestehenden Software-Angebots schlucken werden? Leider wird es wohl nicht ganz so sein. Solange Programme Gebrauch von undokumentierten Systemvariablen machen oder trotz GEM auf bestimmte Bildschirmauflösungen angewiesen sind, wird es erneut Ärger beim Umstieg auf einen neuen Rechner geben. Die Zahl solcher Programme geht jedoch stetig zurück. Die meisten Programmierer richten spätestens seit dem Erscheinen des TT ihr Augenmerk auf das, was unter das Schlagwort „Saubere Programmierung“ fällt. Aber dennoch: Ich müßte nicht lange überlegen, um Programme zu nennen, die zwar auf dem TT laufen, aber weiterhin nicht auf undokumentierte Systemvariablen verzichten.
Ataris Aufgabe
Will man einen neuen Rechner auf dem Markt einführen, muß nicht nur die Hardware stimmen. Mindestens genauso wichtig ist es, das zugehörige Betriebssystem möglichst optimal auf eine neue Architektur abzustimmen. Dies wurde beim TT in einigen Punkten versäumt. Der 68040 ist für Multitasking-Systeme geradezu prädestiniert. Sinnvoll ist ein Betriebssystem für diesem Prozessor jedoch nur dann, wenn diese Fähigkeit unterstützt wird. Ähnlich sieht es mit der virtuellen Speicherverwaltung aus [2], Es kann nicht angehen, daß neue Rechner lediglich mit mehr Geschwindigkeit aufwarten, weiter aber nichts wirklich Neues zu bieten haben. (Wer dies als einen Seitenhieb auf die DOS-Welt versteht, liegt goldrichtig.)
Vielleicht wird man ja nur bis zur nächsten CeBIT warten müssen, um einen Blick auf einen neuen Atari-Computer mit 68040 zu werfen. Wie die Vergangenheit gezeigt hat, kann von der Vorstellung eines neuen Rechners bis zur Auslieferung an den Endkunden viel Zeit vergehen. Aber vielleicht läßt der 68040 ja gar nicht so lange auf sich warten. Zwar ist es nicht ohne weiteres möglich, eine 68040-Karte in den TT einzubauen, aber dank findiger Hardware-Bastler gibt es ja auch bereits die 68030-Karte mit 50 MHz Taktfrequenz für den ST...
US
Literatur:
[1] „Wie ST-kompatibel ist der TT?“, ST-Computer 10190
[2] „Virtuelle Speicherverwaltung, Eine Fallstudie“, ST-Computer 7,8/91
[3] Hilf, „Mikroprozessoren für 32-Bit-Systeme“ Band 1&2, Markt & Technik Verlag AG
[4] „MC68040 User’s Manual“, Motorola Inc.
Uwe Seimet