KMAX - 7,5 Millionen Instruktionen pro Sekunde auf dem ST
Eine Transputerkarte für den Atari: Darauf haben die Rechenleistungsfanatiker gewartet. Ein 32-Bit-Transputerchip vom Typ INMOS T414 sorgt für absolute Höchstleistungen. Wie im Konzept der Transputer vorgesehen, ist auch der Anschluß zusätzlicher Chips für theoretisch unbegrenzte Geschwindigkeit völlig problemlos. Aber was ist eigentlich ein Transputer? Keine Angst, bevor wir näher auf die KMAX-Erweiterung von Kuma Computers aus England eingehen, soll zunächst über Transputer und die dazugehörigen Konzepte, zum Beispiel RISC, berichtet werden.
I. Was ist ein Transputer?
Ein Transputer ist im Grunde ein Mikroprozessor. Seine Architektur orientiert sich im wesentlichen an zwei Konzepten. Zunächst wäre das RISC-Konzept zu nennen. RISC bedeutet ’Reduced Instruction Set Computer’, also 'Computer mit reduziertem Befehlssatz’. Um die Bedeutung dieses Konzeptes zu verstehen, muß man sich einiges aus der Prozessorarchitektur und der Geschichte der Mikroprozessoren vergegenwärtigen.
Zuerst zur Historie. Die ersten Mikroprozessoren waren recht einfach konzipiert. Sie enthielten nur einige wenige Befehle, die insgesamt auch nicht besonders mächtig waren. Die Entwicklung ging in der Folgezeit einen ähnlichen Weg wie bei der Programmiersprache Basic. Man fügte immer mehr Befehle hinzu, die zum Teil recht komplexe Aufgaben mit einem Befehl erledigen. Ein anderes Beispiel ist die Sprache ADA, die im amerikanischen Verteidigungsministerium entwickelt wurde. Die Komplexität hat aber einige Nachteile: Zuerst einmal wird ein Interpreter, der eine große Anzahl von verschiedenen Befehlen ausführen muß, zwangsläufig langsamer als eine kompaktere Version. Auch der Befehlsdecoder eines Mikroprozessors ist im Prinzip eine Art Interpreter, der durch einen großen Befehlssatz langsam wird. Zum anderen zeigt sich in der Praxis, daß die hochkomplexen, dadurch natürlich auch sehr speziellen Befehle nur selten genutzt werden. Im Gegenteil, es kann bei entsprechenden Strukturierungsmöglichkeiten (zum Beispiel bei einer Hochsprache) durch Modularisierung und hierarchisches Konzept fast immer günstiger und einfacher sein, selbst ein entsprechendes Modul aus einfachen Befehlen zusammenzubauen. Ein weiteres Problem der Befehlsvielfalt, an dem besonders ADA krankt, ist die Schwierigkeit, sich all diese Befehle auch zu merken, was nun einmal notwendig ist.
Aber zurück zur Historie. Die Mikroprozessoren wurden immer komplexer und schneller. Dennoch zeigten sich Grenzen der konventionellen Technik. Anlaß für diese Entwicklung war der Glaube, daß die Entwicklung von Compilern für Hochsprachen durch möglichst große Befehlsvielfalt erleichten würde. In den letzten Jahren stellte sich das jedoch als Irrtum heraus. Die Compilerbauer verwenden, wie statistische Untersuchungen zeigen, viel lieber die einfachen Grundbefehle. Überlegungen zur Prozessorarchitektur zeigen darüber hinaus, daß es erheblich effizienter ist, Interpreter, also Decoder, für einfache Maschinensprachen zu bauen. Komplexe Befehlssätze erfordern nicht nur deshalb mehr Zeit, weil bei der Interpretierung mehr Befehle berücksichtigt werden müssen, sondern auch deshalb, weil für komplizierte Befehle sogenannte Mikroprogrammsteuerungen verwendet werden müssen. Ein Mikroprogramm ist ein prozessorinterner Ablauf von Steuerbefehlen, deren einzelne Bits direkt die ausführenden Teile des Prozessors ansteuern. Diese Befehle sind in einem internen ROM gespeichert. Auch der Befehlssatz des 68000 ist auf diese Weise implementiert. Der Vorteil dieses Verfahrens ist die verhältnismäßige Einfachheit, mit der der Befehlssatz einer CPU bei der Herstellung geändert werden kann. Der große Nachteil ist, daß Mikroprogrammsteuerungen auf dem Chip sehr viel Platz in Anspruch nehmen. Dieser Platz steht nicht mehr für andere Dinge wie Register, schnelle Rechenwerke, Cache-Speicher und ähnliches zur Verfügung. Außerdem besteht ein Mikroprogramm selbst für einen einfachen Befehl off aus mehreren Schritten, wobei jeder Schritt einen Taktzyklus benötigt. Dadurch wird die Ausführungszeit erhöht.
Bei einem speziellen, einfachen Befehlssatz kann man beide Probleme umgehen. An die Stelle der Mikroprogrammsteuerung tritt eine Hardware, die die Decodierung der Befehle direkt in einem Schritt erledigt. Bis zu einer gewissen Anzahl von Befehlen ist dieses Verfahren schneller und platzsparender als Mikroprogramme. Da die Größe einer Dekodierungshardware aber leider nicht nur linear mit dem Befehlssatz anwächst, ist man tatsächlich sehr eingeschränkt. Den durch Hardware-Steuerungen gewonnenen Platz kann man zum Beispiel für eine große Anzahl von Registern verwenden. Das hat den Vorteil, das die Zahl der zeitraubenden Speicherzugriffe reduziert werden kann, weil mehr Programmteile in Registern gehalten werden können. Die einfachen Befehle können auch in kürzester Zeit abgearbeitet werden. Typische RISC-Architekturen haben daher weit unter 100, oft nur zwei Dutzend Befehle und manchmal über 1000 Register. Die Anzahl der Instruktionen pro Sekunde ist dadurch bei einem solchen Prozessor extrem hoch. Compiler arbeiten auf RISC-Maschinen oft extrem effizient und produzieren einen Code, der kaum noch zu optimieren ist.
Haben Sie bitte Verständnis dafür, wenn diese Einführung in das RISC-Konzept stark vereinfacht ist. Leider haben wir nicht genügend Platz, uns diesem Thema mit der gebührenden Präzision zu widmen.
Die RISC-Idee ist in der Transputer-Konzeption auf eine recht eigenwillige Art verwirklicht. Zwar hat der Prozessor eine relativ geringe Anzahl von Befehlen (111 - für eine 'klassische’ RISC-Architektur sind es sogar noch recht viele), die Abarbeitung erfolgt jedoch nicht über eine Hardware-Steuerung. Auch besitzt der Prozessor nur sechs Register, was der RlSC-Philosophie entgegensteht. Vor allem gibt es außer dem User-Stackpointer nur drei Allzweckregister, die intern als eine Art Mini-Stack fungieren. Dafür sind allerdings auf dem Chip 2 KByte extrem schnelles statisches RAM implementiert, das die Register recht gut ersetzen kann. Es gibt nur eine einzige Adressierungsart; mehr als zwei Adressierungsarten besitzt praktisch keine RISC-Maschine. Zum Vergleich seien hier die Daten einer typischen RISC-Architektur genannt. Es handelt sich dabei um die RISC-El der Berkeley-Universität: 39 Befehle, 2 Adressierungsarten, fast alle Befehle benötigen nur einen Taktzyklus, 140 Register, Hardware-Steuerung. An dieser Stelle soll zum Thema RISC nicht mehr gesagt werden, obwohl es noch vieles zu diesem Konzept der Zukunft anzumerken gäbe.
Das zweite Konzept, das man bei der Entwicklung der Transputer berücksichtigte, stammt aus der theoretischen Informatik. Es handelt sich hierbei um das Prozeß-Modell, in dem jeder Ablauf als Prozeß dargestellt wird, der durch Nachrichten mit anderen Prozessen kommunizieren kann. Ein Prozeß wird durch eine ankommende Nachricht angestoßen und gibt nach Beendigung eine Nachricht zurück. Selbstverständlich kann ein Prozeß auch weitere Prozesse anstoßen. Auch eine Summe von Prozessen kann wieder als Prozeß aufgefasst werden. In den Transputern ist das Prozeß-Modell höchst interessant verwirklicht: Jeder Chip verfügt über vier superschnelle bidirektionale serielle Schnittstellen, die mit bis zu 20 Megabaud senden und empfangen können. Diese Schnittstellen können für Nachrichten im Sinne des Prozeßmodells verwendet werden. Arbeitet nur ein Transputer, wirkt das ganze Konzept nicht besonders aufregend. Spannend wird es aber, wenn man an die Verschaltung einer ganzen Anzahl solcher Chips denkt. Wie gesagt, man kann auch eine ganze Reihe von Prozessen zusammen wieder als einen Prozeß auffassen. Ein Programm, das auf einem Transputer läuft, kann man sich also als eine Reihe von Prozessen vorstellen, die untereinander transputerintern kommunizieren. Das gleiche Programm könnte aber auch auf mehreren Transputern laufen; jedem Transputer, der über seinen eigenen privaten Speicher verfügt, wird ein Prozeß zugeordnet. Die seriellen Schnittstellen, die übrigens als 'Links' bezeichnet sind, übernehmen dann die Rolle des Mediums für die Übertragung von Nachrichten zwischen den einzelnen Prozessen. Besonders effizient kann dieses Konzept mit der von INMOS speziell für diesen Zweck entwickelten Sprache OCCAM ausgenutzt werden (andere Hochsprachen wie C, Pascal oder Fortran sind ebenfalls möglich). OCCAM erlaubt die Programmierung von Parallel-Verarbeitung (in einer der nächsten Ausgaben wird OCCAM ausführlicher besprochen werden).
Damit ist das Zauberwort gefallen. Parallele Ausführung verschiedener Programmteile zur Geschwindigkeitssteigerung ist das zentrale Konzept aller Rechnerkonzepte neuerer Generationen. Viele Probleme sind bereits in ihrem Konzept hervorragend geeignet für parallele Bearbeitung, so zum Beispiel die meisten Rechenaufgaben im Bereich Computergrafik. Mit Transputern kann man leicht ein Rechnersystem konzipieren, das die Aufgabe optimal erfüllt. Dennoch kann das komplette Programm genausogut auf einem Transputer entwickelt werden, der gesamte Prozeß läuft dann zwar langsamer, aber es funktioniert. Die Übertragung auf ein anderes System erledigt der Compiler. Natürlich muß der Systemprogrammierer sich selbst Gedanken machen, welche Rechnerstruktur seinem Problem am besten entspricht. Viele mathematische Probleme lassen sich sehr effizient mit einer 'Pipeline' aus hintereinandergeschalteten CPUs lösen, andere wiederum mit einer würfelförmigen Schaltung. Alle diese Schaltungen können mit Transputern mit extrem niedrigem Aufwand erstellt werden. Man braucht keine komplizierten Bussysteme wie bei herkömmlichen Multiprozessorsystemen. Die Transputer können mit minimal zwei Drähten miteinander verbunden werden. Es existieren Spezial-Transputer für die Steuerung von Disk-Drives, die vollständig in ein Transputer-Netzwerk integriert werden können. Den Vogel schießt allerdings ein Floating-Point-Transputer ab, der Fließkommamathematik im 64-Bit-IEEE-Format mit bis zu 1.5 Megaflop (das sind Fließkommaoperationen pro Sekunde!!!) erledigt. Der Floating-Point-Transputer ist übrigens pin- und softwarekompatibel mit der 'normalen' Ausführung. Leider sind die Chips noch sehr teuer. Falls der Preis einmal fällt, ist der Austausch problemlos.
Mit Transputern sind bereits Rechner mit mehreren 100 solcher Bausteine geplant, deren Geschwindigkeit in der absolut höchsten Leistungsklasse liegt.
II. Die KMAX-Transputerkarte
Atari-Benutzer können sich trotz der hohen Preise für die Transputerchips und die dazugehörige Software des sogenannten Transputer Development Systems mit Hilfe der Kuma KMAX-Transputerkarte schon jetzt in diese Zukunftstechnik einarbeiten. Für 995 Pfund, das sind etwa 3000 DM, erhält man ein kleines gelbes Kästchen, das eine Transputerkarte zum Anschluß an den ST enthält. Diese Karte ist, wie bereits erwähnt, mit einem Transputer des Typs T414 sowie 256KByte RAM bestückt. Der T414 ist ein echter 32-Bit-Prozessor. Er wird mit 15 MHz getaktet, was einer Rechenleistung von 7,5 Millionen Instruktionen pro Sekunde entspricht. 2 KByte RAM sind im Prozessor enthalten. Auf der Karte ist Platz für einen zweiten Transputer mit 256 KByte RAM. Leider sind die Fassungen für diese Erweiterungen noch nicht auf die Platine gelötet. Die Garantie für das System bleibt nur erhalten, wenn die Erweiterung von Ku-ma durchgeführt wird.
Der Anschluß der KMAX-Karte erfolgt am Romport über ein Flachbandkabel. Im KMAX-Gehäuse ist eine Interfacekarte enthalten, die Daten, die über einen Parallelport vom Atari geliefert werden, mit Flilfe eines sogenannten Linkadaptors in das INMOS Link-Format übersetzt. Auf diese Weise ist es möglich, mit Hilfe spezieller Software über einen der vier Links mit dem Transputer in Verbindung zu treten und ihn mit Software zu versorgen. Dabei erweist sich das von INMOS vorgesehene Boot-Verfahren als nützlich: Nach einem RESET wartet jeder Transputer solange, bis über einen der Links eine bestimmte Datenfolge gesendet wird, die der Transputer als Programm erkennt, empfängt und schließlich ausführt. Alternativ ist von INMOS auch das Booten von einem ROM vorgesehen, was aber auf der KMAX-Karte nicht möglich ist. Die Transputer-Erweiterung muß also immer vom Atari mit Software gefüttert werden, was für ein Entwicklungssystem auch unbedingt sinnvoll ist. Da der Transputer immer unter Kontrolle des Atari steht, können abgestürzte Transputer-Programme mit Hilfe einer RESET-Leitung immer gestoppt und analysiert werden, obwohl der Atari für laufende Transputer-Programme auch Terminal spielt. Man muß für einen RESET des Transputers nur das Terminalprogramm unterbrechen und die RESET-Leitung für den Transputer setzen. Ganz einfach und sicher, das unangenehme Neubooten des Atari bei Softwarefehlern entfällt. Nachdem jetzt die technische Seite des Transputeranschlusses erklärt ist, soll die mitgelieferte Software erläutert werden. In dieser Hinsicht ist der Lieferumfang des Kuma-Transputersystems eher bescheiden. Im Gegensatz zum Original-INMOS-Transputer-Develop-ment-System, zu dessen Lieferumfang ein OGCAM II-Compiler und eine ganze Reihe von Hilfsprogrammen gehört, ist im Kuma-System im Augenblick nur ein Cross-Assembler enthalten. Dies ist allerdings ein recht leistungsfähiges und komfortables Programm.
Wahrscheinlich wird bei Erscheinen dieses Tests zusätzlich auch ein OCCAM-Compiler, der von Metacomco geschrieben wurde, zur Verfügung stehen. Daß dieser bereits den vollen OCCAM II-Leistungsumfang besitzen wird, ist jedoch unwahrscheinlich.
Zu dem RISC-Processor-Development-System, wie Kuma die KMAX-Erweiterung im Untertitel leicht übertrieben nennt, wird außer dem Assembler eine 52seitige, englische Dokumentation im DIN A4-Format geliefert. In diesem Handbuch wird der Assembler ausführlich beschrieben, außerdem werden alle wichtigen Informationen über die Implementierung des Transputer-Anschlusses an den ST gegeben. Es sollte damit kein Problem sein, auch von eigenen Programmen aus Kontakt mit dem Transputer zu bekommen. Weitere Kapitel des Manuals beschäftigen sich mit dem Datenformat der INMOS-Links, sowie allem weiteren Wissenswerten über die konkrete Hardware-Realisierung der eigentlichen Transputerkarte.
Einige Modifikationen können auf der Karte noch vorgenommen werden; z. B. kann der 15-MHz-Transputer problemlos gegen die schnellere (und teurere) 20-MHz Version ausgetauscht oder die Geschwindigkeit der Links verändert werden. Uber das Transputer-Konzept sollte man allerdings zumindest in groben Zügen Bescheid wissen. Die Dokumentation geht darauf nämlich überhaupt nicht ein. Es ist also notwendig, sich entsprechende Literatur von INMOS zu besorgen. Selbstverständlich kann man an den Transputer auch wie an ein normales Mikroprozessor-System herangehen und die besonderen Spezialitäten, die in seinem Konzept enthalten sind, zuerst einmal übergehen. Damit geht dann allerdings der eigentliche Sinn eines solchen Entwicklungssystems, nämlich die Einarbeitung in eben diese Konzepte, völlig verloren. Kuma hätte ruhig ein wenig mehr über die Transpu-ter-Konzepte ins Handbuch schreiben können. Es fragt sich allerdings, ob man in Assembler der besonderen Stärke der Transputer, nämlich der extremen Vorbereitung für Parallelverarbeitung, auch nur anäherungsweise gerecht werden kann. Eigentlich erfordert dieses Transputerkonzept doch eine etwas mächtigere Sprache, die selbst ebenfalls auf dem Konzept paralleler Prozesse beruht; eben das bereits erwähnte OCCAM. In Verbindung mit anderen, nicht-parallelen Sprachen wie C, Pascal oder Fortran, für die OCCAM, wenn man nicht vollständig in dieser Sprache programmieren will, den kontrollierenden Rahmen abgibt, ist es wohl erst möglich, sinnvolle Anwendungen auf einem Transputer zu schreiben und diese dann auf Transputer-Netzwerke zu übertragen. Auch das Prozeß-Konzept von Modula II könnte auf Transputer-Systemen äußerst interessant sein.
Das Problem der Assembler-Programmierung auf Transputern wird zusätzlich dadurch erschwert, daß INMOS nicht unbedingt begeistert auf die Absicht der Assemblerprogrammierung ihres Lieblingskindes reagiert. Es ist sehr schwierig, vom Hersteller überhaupt Informationen über den Befehlssatz der Transputerchips zu erhalten, was zur Folge hat, daß das Handbuch den Befehlssatz auch nur sehr vage beschreibt. Man hat also eigentlich nur zwei Möglichkeiten: Entweder man probiert alles aus, wie es die Entwickler von Kuma in der Anfangsphase des Projektes auch tun mußten, oder man versucht, sich von INMOS die Originalunterlagen zu beschaffen, was - wie man hört - ein schwieriges und langwieriges Unterfangen sein soll. Der Befehlssatz der Transputer unterteilt sich in zwei Gruppen: Es gibt 16 einfache Befehle, deren Funktion in der Dokumentation recht gut und mit ausreichender Ausführlichkeit beschrieben ist. Dazu gibt es noch knapp hundert weitere Befehle, die nur ohne weitere Erklärungen dem Namen nach mit ihren Operatoren aufgelistet sind. Nicht einmal eine Erklärung über das, was sie tun, ist dabei. Natürlich sind viele der Befehle selbsterklärend, so zum Beispiel ’add’ für addieren. Bei anderen Befehlen ist es dagegen notwendig, etwas mehr über die Struktur des Transputers zu wissen.
Am besten schaut man sich die mitgelieferten Beispiele, einige einfache und zum Teil beeindruckend schnelle Programme, sorgfältig an, um mehr über den Transputer-Assembler zu erfahren.
Alles in allem ist das Handbuch recht brauchbar. Trotzdem wird man um zusätzliche Informationsquellen nicht herumkommen. Außerdem wird sich wohl jeder, der halbwegs ernsthaft mit dem Transputer arbeiten will, so schnell wie möglich einen OCCAM- oder sonstigen Compiler zulegen. Die Assembler-Programmierung ist wohl wirklich nur für den Einstieg oder, später, für extrem zeitkritische Prozeduren gedacht. Meines Erachtens läßt sich einfach alles, was an Transputern über normale Mikroprozessoren hinausgeht, in einer Hochsprache logischer und effizienter, auf gewisse Weise 'natürlicher’ programmieren.
III. Der Cross-Assembler
Bei diesem Programm handelt es sich um ein integriertes Maschinensprache-Entwicklungspaket, das außer dem Assembler einen recht komfortablen Editor, einen Debugger, einen Zeilen-Disassembler und alle Routinen, die zur Programmübergabe an den Transputer benötigt werden, enthält.
Es handelt sich um eine TOS-Applikation. Nach dem Laden meldet sich der Assembler ähnlich wie der Kommandointerpreter mit dem Prompt ’XPA > ’ und wartet auf Kommandos. Im Handbuch wird an Hand von Bedienungsbeispielen sehr übersichtlich in das Programm eingeführt. So hat man rasch ein erstes kurzes Programm erstellt, das sich mit irgendeiner Meldung auf dem Atari-Bildschirm bemerkbar machen soll. Doch wie kommt der Transputer an den Atari-Bildschirm?
Um Daten an den Atari zu übergeben, hat Kuma eine Bibliothek einfacher Terminalroutinen mitgeliefert. Diese Bibliothek liegt im Sourcecode vor, kann also analysiert und vielleicht sogar verstanden oder modifiziert werden. Um diesen Sourcecode in eigenen Programmen zu verwenden, setzt man im Editor einfach den Cursor an die Stelle, an der der einzufügende Text erscheinen soll, und führt ein Kommando zum Einlesen von Text aus. Dabei wird der Text automatisch in den alten Text eingefügt. Durch Diskettenoperationen wird der alte Sourcecode immer nur erweitert, nie einfach überschrieben. Um ein neues Programm einzuladen, muß erst der alte Text gelöscht werden. Ist ein Programm fertiggestellt, wird durch die Taste ’a’ der Assembler aufgerufen. Dieser ist mit 50.000 Instruktionen pro Minute recht flott und schreibt den produzierten Sourcecode gleich automatisch in den Speicher des Transputers. Dabei ist die Speicheradresse frei wählbar. Standardmäßig wird im internen Speicher des Transputer-Chips begonnen, der erheblich schneller als der restliche Speicher auf der Platine ist. Dabei wird ausreichend Platz für den User-Stack reserviert. Sobald man mit der Taste ’g’ ein Programm im Transputer startet, schaltet sich der Assembler in einen Terminal-Modus, in dem der Transputer mit Hilfe der Bibliotheksroutinen auf die Resourcen des Atari zugreifen kann. Falls das Transputer-Programm nicht ganz das Gewünschte tut, kann es jederzeit durch Drücken von Control-A gestoppt werden. Dabei wird der Transputer in einen speziellen Analyse-Modus gesetzt, der dem Assembler die vollständige Kontrolle über den Chip erlaubt. Es ist auch möglich, lediglich den Terminalmodus zu verlassen, indem man Control-C betätigt.
Die gesamte Arbeitsweise ist praktisch, effizient und schnell. Der Editor erlaubt Blockoperationen und führt diese auch schnell aus, der Assembler arbeitet formatfrei, daß heißt, man kann den Text nach Geschmack formatieren, auch mehrere Anweisungen (durch Kommas getrennt) in einer Zeile sind möglich. Die üblichen Pseudo-Anweisungen für die Definition von Datenbereichen sind vorhanden, Labels und Konstanten können definiert werden. Eine spezielle Direktive erlaubt es, bei Verwendung mehrerer Transputer einen bestimmten Code-Abschnitt an einen bestimmten Transputer zu senden. Nach dem ’g’-Kommando führt dann jeder Transputer den ihm zugeordneten Code aus. Dabei ist es völlig gleichgültig, wie, wo und über wieviele Ecken, sprich über wieviele und welche Links, der Transputer angeschlossen ist. Man kann also dem Assembler die Struktur eines Netzwerkes aus Transputern angeben, die Übersendung der Programme an die entsprechenden Chips erledigt er automatisch.
Der Debugger erlaubt die Inspektion und Veränderung beliebiger Speicherbereiche des Transputers. Mit einem besonderen Kommando kann der Disassembler aufgerufen werden, der bei jedem Aufruf jeweils 16 Zeilen Code auf den Bildschirm bringt. Wegen einer Besonderheit der Transputer-Assemblersprache ist es dabei möglich, das der Disassembler-Code anders aussieht als das, was in den Assembler eingegeben wurde. Der Assembler erlaubt nämlich die Abkürzung einiger mühsamer Formulierungen dieser Assembler-Sprache, die der Disassembler dann unabgekürzt zurückübersetzt.
Besonders wichtig für potentielle Anwender, die sich in die Transputertechnik einarbeiten wollen, ist natürlich die Geschwindigkeit einer solchen Erweiterung. Maximal 7,5 Millionen Instruktionen kann der T414-Transputer in seiner 15-MHz-Ausführung bewältigen. Verwendet man die 20-MHz-Version, sind es sogar bis zu 10 Millionen Instruktionen, mit dem Floating-Point-Transputer sogar bis zu 1,5 MFlop bei 64-Bit-IEEE-Fließkommazahlen. Genügen 32 Bit Genauigkeit, steigt die Geschwindigkeit dieses Chips auf mehr als das doppelte.
Leider haben die auf der KMAX-Karte verwendeten Transputerchips noch kleinere Fehler, so daß der 256-KByte Speicher auf der Transputerplatine nur mit einer großen Anzahl von Wait-Zyklen angesprochen werden kann. Die volle Geschwindigkeit erreicht die Karte also nur mit Programmen, die das interne 2K-RAM des Chips ökonomisch nutzen. Ein mitgeliefertes Primzahlenprogramm, das auf dem Sieb des Eratosthenes basiert, erreicht auf der Karte eine Rate von mehr als 1.000.000 Primzahlen pro Minute (52 Sekunden für 1 Million), bei Ausgabe jeder 50.000sten Zahl. 2.000.000 32-Bit-Integer-Zahlen werden in 8 Sekunden miteinander multipliziert. Dabei werden die Zahlen im Speicher gehalten und nicht in Registern. Kuma selbst hat für KMAX in Benchmarks eine ungefähr 5-fache Geschwindikkeitssteige-rung gegenüber dem ST ermittelt. Das dürfte ungefähr der Geschwindigkeit eines 68020 ohne Arithmetik-Coprozessor entsprechen.
Die Geschwindigkeit dieses oder überhaupt eines einzelnen Transputers ist jedoch im Grunde gar nicht so interessant.
Ihre besonderen Stärken entfalten Transputer eben nur in Gruppen -nach dem Motto: Eine starke Gemeinschaft... Man kann eben für nahezu jede Anwendung eine geeignete Hardware-Struktur mit vergleichsweise geringem Aufwand realisieren, deren Leistungsfähigkeit kaum durch das Konzept begrenzt ist. Wichtig an der KMAX-Erweiterung ist, daß es für umgerechnet 3000 Mark möglich ist, sich relativ preiswert in eine echte Zukunftstechnologie, nämlich die der parallelverarbeitenden Computer einzuarbeiten. Die Preise für das Original-Inmos-Entwicklungspaket sind eben doch sehr hoch, auch wenn man die bisher bessere Softwareunterstützung in Betracht zieht. Bei Kuma ist man aber sehr mit der Softwareentwicklung beschäftigt - ein OCCAM-Compiler wird, wie bereits erwähnt, zum Erscheinungsdatum dieses Testes wahrscheinlich zur Verfügung stehen. Kurz vor Redaktionsschluß erreichten uns auch etwas nähere Angaben zu dem OCCAM-System, das übrigens von Metacomco entwickelt wird: Es wird zwei Versionen geben; eine OCCAM-ST-Version, die OCCAM-Programme für den 68000er des ST compiliert und in England inclusive Mehrwertssteuer knapp 60 Pfund kosten wird, sowie ein Cross-Compiler-System, das Ihre Programme auf dem ST für die Transputerkarte compiliert. Der ST-Compiler wird in diesem Paket ebenso enthalten sein wie ein Programm, das die Verteilung von OCCAM-Programmen auf mehrere Transputer erlaubt. Dieses 'große’ Paket wird unter 200 Pfund kosten. Alle Compiler werden vorerst nur den OCCAM-I Leistungsumfang unterstützen, die OCCAM-II Version ist noch nicht soweit. Sobald entsprechende Software zur Verfügung steht, ist das KMAX-Paket ein echtes Transputer-Entwicklungssystem, auf dem auch die Entwicklung großer Transputer-Anwendungen möglich sein dürfte.
(CS)