Ins Detail gegangen: ATARI Transputer & Helios-Betriebssystem

Spätestens nach der Vorstellung des Rechnerprototyps auf der diesjährigen CeBIT war es uns allen, die wir das Gerät in Aktion gesehen haben, klar, daß hier eine kleine Sensation in Sachen Rechenleistung auf dem Tisch stand. Leider war auf der Messe nicht allzuviel an konkreten Informationen zu bekommen, die Rechner waren noch nicht sehr betriebssicher, ganz davon abgesehen, daß jeder, der einmal eine Messe besucht hat, weiß, daß ein ruhiges Gespräch dort kaum möglich ist.

Deshalb hat sich die Redaktion der ST-Computer entschlossen, möglichst schnell eine Gesandschaft in die neblige Kälte der Britischen Inseln zu schicken, die dort nach Wissen forschen sollte. Dies ist ihr Bericht.

Nach langen mühevollen Wegen durch Luft und Land standen wir eines milden Frühlingstages in der schönen Universitätsstadt Cambridge vor einem kleinen Gebäude, das ein wenig zurückgesetzt war gegenüber den Fassaden an der Straße. Ein kleines Schild tat dort kund, daß es sich hier um den Firmensitz der Firma Perihelion Hardware handelte. Perihelion? Wieso nicht ATARI? Um auch Neulingen in der ATARI-Transputerstory den Anschluß zu ermöglichen, hier noch einmal eine genealogische Einführung:

Eine kleine Firma in Cambridge (für Ratefaule: mit Namen Perihelion) arbeitet für die Firma ATARI an einem neuen Rechner, der den Projektnamen ABAQ trägt und auf den Transputerchips der Firma Inrnos basiert. Transputer sind den regelmäßigen Lesern unserer Zeitschrift hoffentlich ein Begriff, haben wir doch bereits in unserer Ausgabe 9/87 über eine Transputer-Zusatzkarte (KMAX von KUMA) für den ST berichtet, sie damals sogar getestet. Welchen offiziellen Namen ABAQ dereinst bekommen wird, weiß noch kein Mensch, lediglich sicher ist, daß das System nicht ABAQ heißen wird. Dabei wäre an sich nichts besonderes, denn Transputerrechner gibt es bereits einige, wenn der Auftraggeber nicht ATARI hieße und sensationell günstige Preise für ein Gerät der oberen Workstation-Klasse mit unbegrenzter Ausbaufähigkeit verspräche. Und wenn es nicht noch eine weitere Finna gäbe, deren Name ebenfalls Perihelion ist, aber um den kleinen Zusatz ‘Software’ erweitert... Der Boss dieser Firma, die unabhängig von Perihelion Hardware ist, ist nämlich ein gewisser Dr.Tim King, allen Amiga-Besitzem als einer der Schöpfer des Amiga-Betriebssy-stems bekannt. Seine Firma Perihelion Software arbeitet nun schon seit mehr als zwei Jahren an einem Betriebssystem für Transputer, das erstmals die besonderen Eigenschaften von Transputerrechnern (Multiprozessorfähigkeit) voll nutzen soll. Es trägt den Namen Helios. In der gesamten Branche hat dieses Betriebssystem viel Aufsehen erregt und wird bereits auf die Rechner von verschiedenen Herstellern angepaßt. Das Betriebssystem ist also keine ATARI-Auftragsarbeit. Das läßt für diesen Rechner hoffen (das schreibt ein ST-geschädigter Programmierer)... Perihelion Hardware wird von Jack Lang und Richard Miller geleitet, die beide auch großen Anteil am Design des Systems haben. Die gute Nachricht zuerst: Die Hardware ist so gut wie fertig, sie läuft so zuverlässig, daß bei Erscheinen dieser Ausgabe die ersten 50 Entwicklermaschinen bereits ausgeliefert sein werden.

Die Hardware

Nun aber eine Beschreibung des Systems: Das Ganze wird ein handliches Format erhalten: Nach der bisherigen Planung soll das ganze System im Gehäuse eines ATARI PC3 Platz finden. Wenn’s denn sein muß... Das Grundgerät ist ein Transputerrechner mit einem Inmos T800-Transputer, der mit 20 MHz getaktet wird. Da der Chip bereits eine Floating-Point-Recheneinheit enthält, entspricht das 1.5 MFlop (!!!) Rechenleistung. Eine Memory-Management-Unit, wie sie von bestimmten Betriebssystemen für den Multitasking-/Multiuserbetrieb gefordert wird, fehlt und kann auch nicht nachgerüstet werden. Da ein Transputersystem aber im allgemeinen als Multiprozessor-Rechner betrieben wird, macht das überhaupt nichts, denn ein spezielles Betriebssystem braucht diese Rechnerklasse deshalb sowieso.

Der Transputer hat Zugriff auf 4 Megabyte RAM. Der Speicher ist ohne Parity-Bit organisiert, was laut den Entwicklern für diese Speichergrößen auch nicht erforderlich ist. Das RAM ist 250 ns schnell, was bedeutet, daß der Transputer im allgemeinen nicht auf den Speicher warten muß: Bei einem Speicherzugriff liest der Transputer ein Wort, das vier Befehle enthält. Für die Ausführung jedes Befehls braucht der Chip 100 ns, so daß die Ausführungszeit pro Wort 400 ns beträgt. Nur bei extremem Zugriff auf Daten wird der Prozessor durch den Speicher leicht gebremst. Man kann 120 ns-RAMs benutzen, aber das nützt nur den Chipherstellem, wenn man Richard Miller glauben darf.

Drei der vier 20 Megabaud schnellen seriellen Schnittstellen, die jeder Transputer besitzt (man nennt sie LINKS; sie dienen vor allem der Kommunikation mehrerer Transputer zu einem Rechnernetz von besonderer Leistung) stehen auf der Rückseite des Gehäuses sowohl in TTL- wie ECL-Norm zur Verfügung. Tastatur und Maus sowie Floppylaufwerk und Schnittstellen entsprechen denen des ST. Kein Wunder, denn als I/O-Controller wird ein abgespeckter Mega-ST fungieren. Dieser I/O-Controller ist normalerweise am vierten Link des Haupttransputers angeschlossen. Grafik-Freaks aufatmen, abgespeckt heißt vor allem: Ein Mega-ST ohne Videoteil. Das hat die Hauptplatine des Systems nämlich selbst. Dafür dürfen die Sound-Tüftler weinen: Die Tonerzeugung wird die gleiche sein wie im ST. Aber als Spiele-Maschine wird man einen Rechner, der in direkter Konkurrenz zu Apollo und Sun, ja sogar zu IRIS-Workstations stehen wird, wohl sowieso nur selten verwenden.

Nur auf die Festplatte hat der Transputer aus Geschwindigkeitsgründen einen eigenen, DMA-gesteuerten Zugriff: Ein echtes SCSI-Interface ist vorhanden, eine 40 Megabyte-Platte wird im Grundsystem enthalten sein. Es soll allerdings auch eine zweite Version des Systems geben, die kein I/O-Board enthält, sondern direkt mit einem externen Mega-ST kommuniziert (mit Hilfe einer Steckkarte für den internen Slot des Mega-ST). Diese Version wird allerdings nicht erheblich billiger sein, und auch die Entwickler selbst halten sie nicht für besonders interessant.

Erweiterungen gibt es schon

Für Erweiterungen wird auf die Hauptplatine eine Busplatine mit vier Slots aufgesteckt. An diesen Slots steht der gesamte Bus des Transputers zur Verfügung, so daß hier beliebige Peripherie angeschlossen werden kann. Schon jetzt stehen einige Karten zur Verfügung: - Die Farmcards. Dies sind Transputerkarten, die mit maximal vier Transputern mit jeweils 1 Megabyte RAM bestückt werden können. Die Links der Transputer können mit Jumpern auf der Platine zu einem beliebigen Netzwerk verschaltet werden. Aus Temperaturgründen sollten aber nicht mehr als drei Farmcards in ein Grundgehäuse eingebaut werden. Ein Slot bleibt also für andere Dinge frei. Damit kann das Grundgerät mit bis zu 13 Transputern (Fast 20 MFlop Rechenleistung) ausgestattet werden, dem externen Anschluß weiterer Prozessoren steht natürlich nichts im Wege.

Geplant sind auch Transputer-Erweiterungskarten im Inmos TRAM-Format. TRAMs sind handliche kleine Module, die aus etwas RAM (es gibt verschiedene Größen) und einem Transputer bestehen und huckepack auf eine spezielle Busplatine aufgesteckt werden können. Sehr praktische Tierchen.

Außerdem wird es eine Erweiterungsbox für bis zu 12 Farmcards geben. Damit kann man sich, wie Jack Lang spöttisch bemerkt, fast die Rechenleistung eines CRAY 1-Großrechners, nämlich gut 500 MIPS auf den Schreibtisch stellen. Natürlich kann man auch beliebig viele solcher Zusatzboxen an das System anschließen. Für Grafikaufgaben gibt es bereits Rechner mit mehr als 300 Transputem, Supercomputer mit mehreren Tausend Transputem sind in Planung... Bauen Sie sich Ihren eigenen. Nur eine Geldfrage. Leider sind die dynamischen Rams jetzt ja so teuer... Die Erweiterungskarten werden übrigens nicht von ATARI, sondern direkt von Perihelion vertrieben.

Grafik zum Träumen...

Apropos Grafik - Die Grafikkarte des Transputersystems hat es in sich. Schließlich hat man sich beim Entwurf des Systems von der Philosophie leiten lassen, daß die Hardware schneller Grafiksoftware sowenig wie möglich im Wege stehen soll: Für den Bildschirm steht 1 Megabyte Videospeicher zur Verfügung. Der Videospeicher besteht aus einem sogenannten Dual-Port-RAM, das ist ein Speicher, auf den zwei Teilnehmer gleichzeitig zugreifen können, in diesem Fall der Prozessor und die Videologik, die die eigentliche Ausgabe erledigt. Der Grund für die Verwendung von teurem Dual-Port-RAM ist, daß der Rechnerbus normalerweise durch die Videologik stark belastet wird. 30-40% der Busbandbreite geht dem Prozessor in einem System wie zum Beispiel dem ACORN ARCHIMEDES, der den Videospeicher im normalen RAM-Bereich hat, verloren, was den Speicherzugriff eines so schnellen Prozessors stark verlangsamt und damit den Befehlsdurchsatz in Mitleidenschaft zieht. Bei Systemen, die extrem viele Farben gleichzeitig darstellen können, ist die Busbandbreite überhaupt der größte Engpass für die Systemleistung. Die Videologik beansprucht in solchen Systemen bis zu 70% der Busbandbreite mit den entsprechenden Leistungsverlusten. Durch das Dual-Port-RAM wird laut Jack Lang die Belastung auf weniger als 1 % der Busbandbreite reduziert. Unterstützt wird der Prozessor durch einen Spezialblitter, der dem System zu enormen Grafikleistungen im 2D-Bereich verhilft. Bis zu 128 Millionen Pixel pro Sekunde können bewegt werden, Schrift kann mit bis zu 64 Millionen Pixeln pro Sekunde dargestellt werden, auch Farboperationen kann der Blitter ausführen. Bei unserem Besuch hieß es sogar, daß die Leistungen des Chips, der übrigens den Namen ‘Charity’ trägt, sogar noch höher werden könnten. ‘Charity’ ist ein Gate-Array-Chip, der auch noch die Speicherverwaltung (Refresh usw.) für den Hauptspeicher enthält. 97% der Chipfläche sind durch die Schaltungen belegt, ein sehr hoher Ausnutzungsgrad. Die Schaltung wurde übrigens von Richard Miller entwickelt, nach Vorarbeiten, die an der Universität von Bath geleistet wurden. Was der Blitter grundsätzlich tut, sehen Sie in Bild 6. Die wichtigsten Grafikmodi, die der Blitter ermöglicht, sind folgende:

Insgesamt stehen dann sogar 32 Bit pro Pixel zur Verfügung, die aber zum Teil für Overlay-Flags verwendet werden, z.B. für den Mauscursor oder blinkende Zeichen. Die restlichen 5 Bits bleiben für eigene Zwecke übrig, zum Beispiel für 3D-Tiefeninformationen. Die Flag-Bits können aber auch deaktiviert werden, so daß dann 8 Bit für eigene Zwecke zur Verfügung stehen.

Der Blitter ist aber extrem vielseitig. Es können also auch andere Modi selbst programmiert werden. Es ist möglich, die horizontale und vertikale Sync-Frequenz weitgehend frei zu programmieren. Auch mit den Farbpaletten sind zahlreiche Manipulationen möglich. Zum Beispiel ist es möglich, mehrere Bitplanes verschiedener Farbauflösung gleichzeitig zu verwenden.

Auch Hardware-Panning und Zooming ist möglich. Sogar gewisse Formen von Anti-Aliasing sollen vom Blitter hardwaremäßig unterstützt werden. Leider wurde über diesen extrem wichtigen Punkt noch nichts näheres verraten. Ein spezielles Blittermanual ist aber in Vorbereitung und sollte bei Erscheinen dieses Artikels lieferbar sein (bei ATARI England). Eine Grafik-Library für den Blitter soll auch bereits in Arbeit sein. Nach allem was bisher bekannt wurde, ermöglicht der Blitter aber wirklich bombastische Grafikleistungen im 2D-Bereich (Der Autor litt während der ‘Fragestunde’ an schweren Enthusiasmus-Anfällen).

Der Bildschirmspeicher wird übrigens immer so in den Adressraum des Transputers gemappt, daß unabhängig von der tatsächlichen Farbtiefe des Grafikmodus immer auf die gleiche Weise auf den Grafikspeicher zugegriffen werden kann. Das erspart zeitraubende Umrechnungen von Koordinaten, wie sie in den Farbmodi des ST notwendig sind. Der Speicher ist immer linear angeordnet. Wie schön. Man muß nie multiplizieren, schnelle Stuft’s reichen immer aus, um an die gewünschten Speicheradressen zu kommen.

...und für Profis

Für besondere Videoleistungen soll es auch möglich sein, drei Grundplatinen so zu koppeln, daß die hohen Auflösungen mit 16,7 Millionen Farben verwendet werden können. Dabei beschäftigt sich dann jede Platine nur mit einer der Grundfarben. Das damit auch die dreifache Rechenleistung zur Verfügung steht, sei nur am Rande erwähnt.

Genlockfähig ist die Grundplatine bereits, es kann also in den Bildschirmhintergrund ein beliebiges Videobild eingeblendet werden. Dieses ewige Schwarz ist ja auch langweilig. Außerdem wollte ich schon immer mal Dallas im Computer sehen (als Animation für Computerspiele). Um jedoch im professionellen Videobereich nutzbar zu sein, muß eine Videokarte in der Lage sein, die entsprechenden Femsehnormen zu erfüllen; sowohl der Interlace-Modus wie auch die Färb- und Signalpegelnormen der Femsehnormen müssen erfüllt sein. Das kann das System in der Grundausstattung nicht, für die meisten Anwendungen von CAD bis Schach ist es ja auch nicht besonders wichtig, eher sogar schädlich. Aber um den Grafik-Workstations von Silicon Graphics wirklich Konkurrenz machen zu können, haben sich die Flerren Lang und Miller entschlossen, eine Zusatzkarte zu entwickeln, die dem Rechner zu genau diesen Möglichkeiten verhilft. Das wird zwar nicht ganz billig werden, soll aber zum Zeitpunkt des Erscheinens des Rechners auf dem offiziellen Markt verfügbar sein. Wenn Sie mich fragen: Wenn sich nur ein paar gute Grafik-Programmierer auf diese Maschine stürzen, wird sie den Markt für professionelle Computergrafik ziemlich durcheinanderwirbeln. Auch eine Video-Digitizer-Karte befindet sich bereits in der Entwicklung, so daß das Scannen von Videobildem möglich wird.

Transputer im Netz

Transputer lassen sich mit FTilfe ihrer Links zu fast beliebigen Strukturen zusammenschalten. Im Grundsystem geschieht dies über Jumper auf den Farmcards. Sogar das I/O-Board muß nicht unbedingt an einen der Links der Hauptplatine angeschlossen sein. Für viele Anwendungen ist es allerdings viel, viel eleganter, wenn man die Hardware per Software in die geeignete Form bringen kann: Einen Würfel zum Suchen in einer Datenbank, eine Matrix oder eine Pipeline für schnelle Grafik oder Mathematik usw. Dazu hat Inmos einen Spezialchip entwickelt, den sogenannten Linkswitch. Natürlich haben auch die Entwickler des ATARI-Transputersystems sich diese Möglichkeit nicht entgehen lassen: Sowohl das Grundsystem wie die Erweiterungsbox lassen sich mit einer Zusatzplatine ausrüsten, die beliebige Konfiguration der Links per Software erlaubt.

Richard Miller und Jack Lang präsentieren das neue Transputer Motherboard

Diagnostik

Das Debuggen von Transputer-Netzwerken ist ein noch ungelöstes Problem. Die Hardware des ATARI-Systems wird es aber erlauben, jeden einzelnen Transputer im Netz anzuhalten, zu ‘resetten’ oder zu analysieren. Wir werden auf dieses Problem aber im Software-Teil noch einmal zurückkommen.

Ein paar Beispiele

Auf der CeBIT waren bereits ein paar Demos zu sehen, die die Rechenleistung eines Systems mit 13 Transputern zeigten; Ein Dhrystone-Benchmark etwa, mit einem Ergebnis in der Größenordnung eines IBM-Mainframes, oder Apfelmännchen in atemberaubendem Tempo. Eine Demoanwendung, von der uns Jack Lang freudestrahlend berichtete, kann z.B. mit 13 Transputern Gouraud-Shading mit 18 Frames pro Sekunde berechnen, mit insgesamt über 5000 Polygonen pro Sekunde. Eine IRIS der 150.000 DM Klasse kann auch nicht mehr (Hah - wenn überhaupt). Außerdem ist so eine Workstation sehr festgelegt, um diese Leistung zu erreichen, muß extrem aufwendige 3D-Grafikhardware verwendet werden, die für nichts anderes zu gebrauchen ist. Jeder Transputer in einem Transputemetz kann seine Leistung aber jederzeit in den Dienst eines neuen Herrn stellen.

Zukunft und Gegenwart - Wie ist der Stand der Dinge?

Das Design der Hardware ist fertig, die Teile funktionieren, es müssen nur noch einige Logik-Schaltkreise in Custom-IC’s zusammengefaßt werden. Die Überhitzungsprobleme, die es auf der CeBIT zu bewundern gab, sind gelöst: Auf der Messe war der Blitter noch nicht fertig, die gesamte Blitterlogik saß auf einer vollbestückten Platine, die unter der Hauptplatine montiert war. Das wurde etwas zu heiß. Der Blitter als Gate-Array wird nicht einmal warm. Auch sonst gibt’s keine Probleme: Fast alles ist CMOS. In den ersten 50 Entwicklermaschinen, die jetzt ausgeliefert werden/ worden sind, ist kein I/O-Board enthalten, es wird ein Mega-ST benötigt. Auch die Harddisk wird im Moment noch vom ST gesteuert: Die Hardware für die SCSI-Schnittstelle ist zwar fertig, wird aber vom Betriebssystem noch nicht unterstützt. Die meisten dieser 50 Geräte werden, wie der bei ATARI England für die Verteilung zuständige Les Player mitteilte, zu Demonstrationszwecken an die verschiedenen ATARI-Ländergesellschaften gehen, von denen es wohl einige gibt. Den mageren Rest werden Softwarehäuser, die an Entwicklungssoftware und Tools arbeiten, erhalten. Alle Geräte werden übrigens in England gefertigt. Die nächsten Maschinen sollen dann im Juni fertig sein. Zu diesem Zeitpunkt dürfte auch die nächste Layout-Revision vorliegen. Ob in diesem Stadium dann schon ein I/O-Board vorliegt, oder immer noch ein Mega-ST benötigt wird, ist noch nicht bekannt. Falls sich am Blitter oder anderen Hardwareteilen funktionell noch etwas ändert, sollen für alle Entwicklermaschinen Hardware-Updates erhältlich sein.

Chip-Designer R. Miller zeigt stolz den neuen Blitterchip für den Transputer. In der rechten Hand ein Prototyp des Blitters.

Das liebe Geld

Doch nun noch ein paar Worte zu den Preisen, die für die Transputerprodukte zu erwarten sind. Im Moment ist der aktuelle Preis für die Entwicklergeräte 3000 £, beim aktuellen Kurs über 9000.- DM. In diesem Preis ist das Betriebssystem samt C-Compiler und Tools nicht enthalten, dafür werden noch einmal 500 £ an Perihelion Software zu zahlen sein. Mit den Produktionsmaschinen soll Helios dann aber serienmäßig mitgeliefert werden. Diese Informationen repräsentieren natürlich nur den allerletzten Stand der Dinge; wie immer bei Entwicklungsgeräten können sich diese Fakten schnell ändern. Die Preise hängen im Moment übrigens sehr stark von den Kosten für dynamische RAMs ab, die in letzter Zeit nur zu hohen Preisen erhältlich sind. Wenn RAMs wieder billiger werden, könnten die Preise für die Transputermaschine noch erheblich fallen. Nach den bisherigen Informationen wird im Endpreis kein Monitor, wohl aber eine 40 MByte Festplatte enthalten sein. Alles in allem wäre dieser Preis für einen Rechner dieser Leistungsklasse mehr als sensationell; selbst im Selbstbau dürfte sich dieser Preis kaum unterbieten lassen, schon gar nicht mit dieser Hardware-Leistung. Der Rechner ist einem Mac II weit überlegen, kostet aber sogar weniger. Für die Workstation-Konkurrenz geht derselbe Vergleich noch viel ungünstiger aus, vorausgesetzt, es wird vernünftige Software für das System geben. Die Chancen dazu sind gut - doch darauf kommen wir gleich zurück. Erst noch einmal ein paar vorläufige Preise für Erweiterungskarten:

Größenvergleich: Der hochintegrierte Blitterchip für den Transputer

Eine Farmcard wird zwischen 995 £ (mit einem Transputer) und 2995 £ (mit vier Transputern) kosten. Speichererweiterungen sind bei den heutigen RAM-Preisen natürlich teuer: 1995 £ wird man, wenn die Preise nicht fallen, für 4 MByte, 4995 £ für 12 Megabyte Speicher bezahlen müssen. Damit sind die Netzwerk-und Kommunikationskarten vergleichsweise billig: Nur 499 £ beträgt der geplante Preis für eine Karte. Noch billiger ist die Link-Switch Karte für die Hauptplatine: Sie soll nur 299 £ kosten. Das Erweiterungschassis für 12 Farmcards schließlich wird, inclusive Netzteil und Lüfter, zwischen 499 £ und 995 £ kosten, je nachdem ob es mit Link-Switch-Karten ausgestattet sein soll oder nicht. Diese Preise sind hier nur erwähnt, um zu zeigen, daß auch die Aufrüstung des Grundgerätes im Verhältnis zum Leistungszuwachs spottbillig ist. Immerhin kommt man mit einem großen Transputersystem in die Leistungsklassen, die bisher nur den in vielen Kleiderschränken untergebrachten Kollegen offenstanden. Abaq bleibt immer recht handlich.

Die Software

Perihelion Software residiert in einem kleinen Ort südlich von Bristol. Dort wurden wir von Tim King empfangen, mit dem wir über Details des Betriebssystems Helios für Transputer sprechen konnten.

Ein Computer braucht ein Betriebssystem. Ein Betriebssystem soll die Resourcen des Rechners möglichst optimal auf die zu lösenden Aufgaben verteilen, ohne dabei selbst zuviel der Resourcen in Anspruch zu nehmen. Auf Workstations und Minicomputern, selbst auf vielen größeren Rechnern ist UNIX heute ein Standard-Betriebssystem. Warum wurde also nicht einfach UNIX an Transputer-Rechner angepaßt, wie es ja auch in der Vergangenheit an zahlreiche, sehr verschiedenartige Rechnerarchitekturen angepaßt wurde?

UNIX ist ein zum größten Teil in C geschriebenes (tatsächlich ist C eigentlich vor allem entstanden, um UNIX neu in einer Hochsprache zu schreiben), multitasking- und multiuserfähiges Betriebssystem. Es ist, wie bereits erwähnt, weit verbreitet und auf sehr unterschiedlichen Rechnertypen lauffähig. Die meisten Implementierungen laufen vermutlich auf 68020-Workstations. Das System ist genormt; es existieren allerdings sehr viele verschiedene Versionen, die zum Teil sehr große Unterschiede in Handling und Dateiverwaltung aufweisen. Fast alle modernen UNIX-Implementierungen werden durch grafische Benutzeroberflächen unterstützt, die häufig auf dem am MIT (Massachusetts Institute of Technology) entwickelten Fenstermanager XWindows aufbauen. Andere Firmen benutzen eigene Grafikoberflächen. Alle diese Gründe sprechen für eine Verwendung von UNIX auf einem neuen Rechnertyp. In der Architektur von Transputersystemen steckt jedoch ein Element, das es geraten sein läßt, ein eigenes, speziell für diese Architektureigenschaft geschriebenes Betriebssystem zu verwenden: UNIX ist für Rechner mit einem einzigen Prozessor konzipiert. Transputerrechner sind aber von vornherein als Multiprozessorsysteme ausgelegt, auch wenn Transputersysteme mit einem Transputer möglich sind. Der eigentliche Vorteil der Transputer ist die Möglichkeit, mit extrem wenig Aufwand Multiprozessorsysteme aufzubauen. Wozu Multiprozessorsysteme?

Tim King, der Schöpfer des Betriebssystems Helios für den ATARI-Transputer

Die Geschwindigkeitssteigerungen, die durch Beschleunigung einzelner Prozessoren erreicht werden können, sind vergleichsweise gering. Die Steigerung von einem 68020 zu einem 68030 beträgt bestenfalls 70%. Hätte man stattdessen die Möglichkeit, das gleiche Problem von zwei Prozessoren der Geschwindigkeit eines 68020 rechnen zu lassen, wäre die Geschwindigkeitssteigerung bereits 100%, ohne daß irgendwelcher Aufwand für Hardware-Neuentwicklung getrieben werden müßte. Aus diesem Grund forscht man schon seit einiger Zeit im Bereich Parallelverarbeitung, vor allem daran, wie man Problemlösungen automatisch parallelisieren kann, wie man die parallele Rechenleistung möglichst effizient für die Lösung von Problemen einsetzen kann? Bei vielen mathematisch/ technischen Problemen ist das recht einfach, andere Probleme machen es sehr schwer. Kurz und gut, ein Transputersystem mit 10 Transputern ist erheblich billiger und flexibler, als es ein einzelner Prozessor mit der gleichen Gesamtleistung sein könnte, vorausgesetzt, es steht Software zur Verfügung, die das Multiprozessorsystem adäquat unterstützt. Aus diesem Grund sind UNIX-Portierungen auf Transputersysteme zwar möglich, aber nur eingeschränkt sinnvoll. Volle Multiprozessor-Unterstützung ist im Konzept von UNIX einfach nicht vorgesehen. Ein weiterer Punkt liegt in der Transputer-Hardware selbst begründet: UNIX beschäftigt sich zu einem guten Teil mit der Umschaltung zwischen Prozessen. Das ist auf einem Transputersystem aber nicht notwendig, da der Transputer bereits hardwaremäßig einen leistungsfähigen Mechanismus zur Prozeßumschaltung besitzt. Das Betriebssystem auf einem solchen Prozessor kann (und muß) sich daher anderen Aufgaben zuwenden. Auch die gleichzeitige Verwendung eines Programmstückes muß in einem Transputersystem anders gelöst werden als in einem Einprozessorsystem. In einem Einprozessorsystem teilt man Code einfach, indem beide Prozesse auf den gleichen Speicherbereich zugreifen. In einem Mehrprozessorsystem reduziert eine solche Lösung für jeden Prozessor die Speicherbandbreite, weshalb Transputer-Rechner im allgemeinen gar keinen Speicherbereich, der für mehr als einen Transputer zugänglich ist, besitzen. Code muß in einem solchen Rechner also durch Kopieren geteilt werden.

Helios

ist ein Betriebssystem, das speziell für Multiprozessorsysteme konzipiert wurde. Es basiert auf Forschungsergebnissen der Universität on Cambridge und anderer Universitäten. Helios ist eines der ersten kommerziell verfügbaren Betriebssysteme, das die Fähigkeiten von Multiprozessorsystemen voll unterstützt. Wie UNIX ist es multitasking-und multiuserfähig.

Im Konzept von Helios wurde aber die Vielzahl von UNIX-An Wendungen (und Anwendern) nicht übersehen. Zusätzlich zu den eigenen Funktionen bietet Helios eine C-Library, die weitgehend UNIX-kompatibel ist, soweit das eben auf einem Multiprozessorsystem sinnvoll möglich ist. Laut Tim King strebt man damit an, “zumindest so kompatibel zu UNIX zu sein, wie es die einzelnen UNIX-Implementierungen untereinander sind”. Man hofft, den POSEX-Standard für UNIX vollständig erfüllen zu können. Ganz ohne Änderungen lassen sich nämlich Programme zwischen den verschiedenen UNIX-Versionen nicht austauschen. Ähnlich einfach sollen also auch die Änderungen für UNIX-Programme sein, die unter Helios laufen. Solche Programme sind für Helios dann ein einzelner Prozess, sie gewinnen also nicht an Geschwindigkeit durch das Vorhandensein weiterer Prozessoren (es sei denn dadurch, daß ein Prozessor dann nicht durch mehrere Prozesse belastet wird, wenn mehrere Programme oder Benutzer gleichzeitig mit dem Rechner arbeiten). Schwierigkeiten gibt es im Moment noch mit FORK-/EXEC-Aufrufen zur Generierung von Prozessen, die sich unter Helios viel einfacher gestalten lassen, auf einem Transputer aber sehr schwierig in der UNIX-Form zu implementieren sind, sowie mit IOCTL-Calls.

Die Arbeitsweise unter Helios wird aber auf jeden Fall der unter UNIX entsprechen; die C-Shell sowie das Make-Utility sind voll mit UNIX kompatibel.

Die UNIX-Library hat für Programmierer, die von UNIX-Computern kommen, aber auch noch weitere Vorteile: Die Programmierung ähnelt auch dann, wenn man Programme unter Helios (mit voller Nutzung der Parallelisierung) schreibt, der Programmierung eines UNIX Rechners. Helios ist zwar keine UNIX-Version, für den Benutzer erscheint es aber UNIX-verwandt. Das erleichtert natürlich erheblich die Einarbeitung.

Auch die ANSI-C-Library wird zur Verfügung stehen, so daß auch Übertragungen aus der MS-DOS-Welt recht schnell verfügbar sein könnten. Der Programmierer hat dann die Wahl, ob er bestimmte Funktionen über die ANSI- oder UNIX-Library oder durch direkten Zugriff auf die Helios-Library aufrufen möchte (siehe Bild 7).

Der Overhead, der durch den indirekten Aufruf von Helios-Funktionen über die externen Libraries entsteht, wird nach Worten von Tim King im allgemeinen sehr gering sein. Besonders die Arbeitsweise vieler UNIX-Anwendungen, die ein Endergebnis erst nach Aufruf vieler Teilprozesse ergeben, läßt sich leicht auf Helios übertragen, bei voller Nutzung der Parallelverarbeitung. Diese Art ‘pseudo-paralleler’ Programmierung ist sehr leicht zu verstehen und anzuwenden.

Schließlich ermöglicht Helios aber auch die konsequente Nutzung echt paralleler Algorithmen. Beispiele für leicht parallelisierbare Probleme sind z.B. Grafik-Berechnungen, Finite-Elemente-Analyse, Datenbank-Suche, Tabellenkalkulationen usw. Ein kleineres Problem, das sich durch Einsatz paralleler Prozesse leicht beschleunigen läßt, ist zum Beispiel eine einfache Matrixmultiplikation. Das Hauptproblem bei parallelen Prozessen ist die Kommunikation und Synchronisation verschiedener Abläufe. Dafür stellt Helios entsprechende Mittel zur Verfügung.

Helios ist ein verteiltes Betriebssystem. Das heißt, daß es keine besonderen Funktionen im Prozessometz-werk gibt, die das System zu einem Totalausfall bringen könnten. Selbst wenn ein Prozessor in den Generalstreik tritt, ist die Ausführung von Programmen nicht gefährdet, schlimmstenfalls erhöht sich die Ausführungszeit. Ein Prozeß muß nie wissen, auf welchem Prozessor er läuft, oder an welchen Prozessor der Bildschirm angeschlossen ist? Unfall diese Dinge kümmert sich das Betriebssystem automatisch. Im Prinzip stellt Helios die Infrastruktur für die Verteilung und Kommunikation von Prozessen auf einem Multiprozessorsystem zur Verfügung.

Geschrieben wurde Helios übrigens in einer Mischung aus Assembler und C, genau wie auch UNIX zum überwiegenden Teil in C geschrieben ist. Da Helios ein Multiuser-Betriebssystem ist, können mehrere Benutzer gleichzeitig Programme auf dem Rechner laufen lassen. Anwendungen heißen in diesem Zusammenhang ‘Task’. Tasks bestehen im allgemeinen aus mehreren Prozessen, die in beliebigen Sprachen geschrieben sein können, da die gesamte Kommunikation auf Betriebssystem-Ebene erfolgt. Das Ganze basiert auf dem sogenannten Client-Server-Modell. Das bedeutet, daß die Applikation vom Betriebssystem bestimmte Dienste erfordert, die selbst wiederum nur ein Task auf irgendeinem Prozessor zu sein brauchen. Der einzige Task, der auf allen Prozessoren vorhanden sein muß, ist ein Task, der die anderen Server-Tasks zu finden vermag, wenn sie gebraucht werden. Server sind beispielsweise Dateisysteme (z.B. für Floppy oder Festplatte), Fensterverwaltungen, Druckeransteuerungen usw. Für die Kommunikation mit den einzelnen Servern ist ein bestimmtes Protokoll festgelegt. Um z.B. ein anderes Floppyformat für das Betriebssystem verfügbar zu machen, muß nur ein entsprechender Server vorhanden sein, der sich an das Kommunikationsprotokoll hält. Auf diese Art kann man das System leicht an die vorhandene Hardware anpassen, ohne daß das Gesamtsystem oder auch einzelne Prozessoren mit unnützen Server-Tasks belastet werden müßten (der Floppy-Server muß eben nur auf dem Transputer, der mit dem Floppy-Controller verbunden ist, laufen). Ein Beispiel: Der Floppy-Server von Helios für das ATARI-System unterstützt MS-DOS und ST-Format, während die Harddisks im UNIX-Format benutzt werden.

Bild 6: Der Aufbau des Transputer-Blitters

Flexibilität - Auf dem Weg zu einem Standard?

Wichtig ist, daß Helios nicht an eine bestimmte Hardware-Konfiguration gebunden ist. Das System ist so konzipiert, daß es auf nahezu jeder Transputer-Hardware läuft. Bereits jetzt werden verschiedene Systeme von verschiedenen Herstellern unterstützt. Helios hat daher gute Chancen, ein Standard auf dem Gebiet der Transputer-Betriebssysteme zu werden, zumal bisher keine ähnlich weit gereifte Alternative in Sicht zu sein scheint (die meisten anderen bisher vorgestellten Lösungsvorschläge basieren auf UNI-Portierungen, die einem Transputersystem eben nicht in genügender Weise gerecht werden). Das große Interesse an Helios, das zahlreiche Hersteller von Transputerrechnem bekundet haben, läßt hoffen. Parsytech aus Aachen und Meiko in Bristol sind nur zwei Beispiele großer Transputer-Systemhäuser, die Helios bereits benutzen oder zumindest sehr daran interessiert sind (Tim King zählte eine ganze Liste auf). Selbst der Transputer-Erfinder INMOS zeigt große Neugier. Tatsächlich angepaßt wurde Helios bisher für die ATARI-Maschine, die Kuma Transputerboards (die wir bereits getestet haben), das Parsytech Megaframe-System, den Microwy Monoputer und das Inmos B004 Plug-In-Board für den IBM PC. Die Liste der angepaßten Systeme wird aber laut Perihelion von Tag zu Tag länger.

Kommunikationsdesign und Overhead

Der Kommunikationsmechanismus für Prozesse unter Helios basiert auf der Übergabe von Mitteilungen. Eine Mitteilung besteht aus einem festen Kopf (12 Byte) und den eigentlichen Daten. Ein Prozeß muß nicht wissen, wo sich der Zielprozeß befindet, Helios sorgt selbstständig dafür, daß eine Nachricht ihr Ziel erreicht. Physikalisch werden Mitteilungen, wenn die Prozesse sich nicht auf dem gleichen Prozessor befinden, über die Links des Transputers verschickt. Leider ist die Geschwindigkeit dieser Links beschränkt. Bei einem mit 20 MHz getakteten Transputer können 20 Megabit pro Sekunde übertragen werden. Sind Sender und Empfänger direkt benachbart, also nicht durch dazwischenliegende Transputer beschränkt, können ungefähr 1.2 Megabyte in Paketen von 1024 Byte Größe verschickt werden. Wenn 20 Transputer zwischen Sender und Empfänger liegen, reduziert sich die Übertragungsrate auf 70 KByte, ein ziemlich beträchtlicher Verlust. Je größer ein Datenpaket ist, desto weniger wirkt sich natürlich der Mitteilungskopf aus, es ist also effektiver, wenige große Mitteilungen zu versenden. Glücklicherweise ist der Link-Anschluß der Transputer mit DMA ausgestattet. Das bedeutet, daß der Prozessor nicht ständig auf der Lauer liegen muß, ob irgendeine Nachricht eintrifft. Während ein Prozeß darauf wartet, daß der Server ihm das Eintreffen einer Nachricht meldet, kann der Transputer mit anderen Prozessen weitermachen.

Der Overhead von Helios für Prozeß-Umschaltungen ist gleich Null, da dies direkt von der Transputer-Hardware erledigt wird. Auch für die Verwaltung von Tasks usw. sind die Verluste durch Helios gering. Natürlich dauert bei einem umfangreichen Transputer-Netzwerk die Initialisierungsphase für komplexe Programme mit vielen Prozessen immer länger, als bei einem Einprozessorsystem. Schließlich müssen die einzelnen Programmteile erst einmal an ihren Bestimmungsort transferiert werden.

Speicherbedarf

Helios benötigt in jedem Prozessor verhältnismäßig wenig Speicher. Der sogenannte Nucleus, der die wesentlichen Elemente des Betriebssystems für jeden Prozessor enthält, ist nur 40 KByte lang. Für eine Shell werden ungefähr 70 KByte benötigt, eine Shell muß aber nicht in jedem Prozessor vorhanden sein, genausowenig wie die C-Library, die ungefähr 40 KByte schluckt.

Die gesamte Speicherverwaltung wird von Helios übernommen. Ob ein Programm im transputerinternen, superschnellen Speicher oder im normalen Hauptspeicher des Transputers steht, entscheidet Helios.

Benutzerinterface und Grafik

Der Benutzer kann Helios (bzw. den mit Helios laufenden Computer) über die bereits erwähnte Shell, die weitgehend der Unix-C-Shell entspricht, bedienen. Eine Shell kann in jedem Prozessor laufen, auch beliebig viele Shells gleichzeitig. Dabei muß die Shell, wie jeder andere Prozeß auch, nicht einmal wissen, wo der Bildschirm ist. Sie schickt einfach nur ihre Aufgaben an den für Bildschirme zuständigen Server, Helios findet ihn selbständig, der Server kümmert sich um die Ausgabe (und flucht dabei still vor sich hin über den unpersönlichen Arbeitsstil).

Falls eine Grafikkarte an das System angeschlossen ist, kann das von MIT entwickelte XWindows-Protokoll verwendet werden. XWindows ist ein ebenfalls auf dem Client/Server-Modell basierendes Fenstersystem, das deshalb hervorragend in das Helios-Konzept paßt. XWindows ist außerdem sehr weit verbreitet. Bei der Implementierung von XWindows unter Helios hilft die Firma IXI, die auf XWindows spezialisiert ist, um sicherzustellen, daß die Implementierung dem Standard entspricht. Näheres über XWindows finden Sie in einem Info-Kasten am Ende des Artikels.

Die Anpassung von XWindows an Helios und speziell für das ATARI-Transputersystem ist noch nicht fertig: Da XWindows ein sehr umfangreiches System ist (ca. 13 Megabyte Source !) ist eine Menge Anpassungsarbeit zu leisten. Ein rein in Software implementiertes XWindows wäre nämlich schrecklich langsam, so daß vieles erst einmal an den Blitter angepaßt werden muß, der sich dann aber so richtig austoben darf. XWindows ist auf jeden Fall sehr geeignet, um Applikationen zu schreiben, die von verschiedenen Prozessoren aus auf einen Bildschirm zugreifen wollen. Für spezielle Grafik-Applikationen hält Mr. King XWindows für weniger effizient, so daß zumindest auf der ATARI-Maschine viele Programmierer, die Applikationen in dieser Richtung schreiben wollen, auf die Benutzung von XWindows verzichten und lieber direkt auf die Hardware zugreifen werden. Eine spezielle Grafiklibrary für den Blitter soll es ja, wie oben erwähnt, auf jeden Fall geben. XWindows wird auf jeden Fall auch nur die oben angegebenen Grafikmodi unterstützen; wer Spezialitäten will, muß auf eigene Routinen zurückgreifen. Wie die XWindows-Implementierung auf anderen Maschinen aussehen wird, hängt natürlich von der Grafik-Hardware der Systeme ab, XWindows ist aber von vornherein auf Portabilität konzipiert worden, so daß die Anpassung keine unüberwindlichen Schwierigkeiten bereiten dürfte.

Bild 7: Die HeliosLibrary

Mieterschutz

Natürlich muß ein Multiuser-Betriebssystem auch einen Schutzmechanismus für Objekte zur Verfügung stellen. Es wäre ja noch schöner, wenn jeder hergelaufenen Prozeß, ohne zu fragen, die gerade von einem anderen Prozeß erzeugte Datei für eigene Zwecke benutzte oder andere Bosheiten vollbrächte. Jedes Objekt ist unter Helios mit einer ‘Berechtigungskarte’ ausgestattet, die den Zugriff auf andere Objekte regelt. Damit ist es weitgehend ausgeschlossen, daß Ihnen jemand in die Suppe spuckt. Einen ‘Super-User’, der von vornherein Zugriff auf alles hat, gibt e s unter Helios nicht. Es ist aber natürlich sinnvoll, wenn der System-Operator mehr Zugriffsrechte hat, als der normale Benutzer, den nur sein eigener Dateibaum etwas angeht.

Prozeßverteilung

Selbstverständlich bietet Helios eine Automatik an, die bei der Vertei-ung von Prozessen auf die vorhandene Hardware hilft. Dazu dient eine sogenannte ‘Component Distribution Language’ (CDL - Komponenten Verteilungs Sprache), die von einem Teil des Betriebssystems dazu genutzt wird, die vorhandene Hardware-Struktur möglichst gut auszunutzen. Dabei werden in Zukunft auch die Linkswitches unterstützt werden, so daß die Hardware auch durch die CDL erst zu einer bestimmten Konfiguration zusammengestellt werden kann. Dies soll dann auch dynamisch während des Programmablaufs funktionieren, so daß ein Prozeß das ganze System wenn nötig neu konfigurieren kann (zum Beispiel kann man aus einer Pipeline, wenn an einer bestimmten Stelle einer Applikation ein Würfel effizienter erscheint, zu diesem Würfel umschalten, und wenn wieder eine andere Transputerstruktur gebraucht wird, auf diese usw.). Möglicherweise werden die Konfigurationsvorgänge von einem eigenen ‘kleinen’ (16 Bit) Transputer vom Typ T212 erledigt werden, der auf der Linkswitch- Platine sitzt.

In der CDL-Beschreibung einer Applikation werden die Erfordernisse (bzw. Wünsche) der einzelnen Prozesse aufgelistet. Ein Prozeß, der mit der Verwaltung von Disketten-Datei-en beschäftigt ist, teilt zum Beispiel mit, daß er gerne auf einem Prozessor in unmittelbarer Floppycontroller-Nähe beschäftigt sein möchte. Ein anderer Prozeß teilt mit, daß er mindestens 3 Megabyte RAM benötigt. Der nächste Prozeß wünscht unmittelbaren Grafikzugriff. Ein weiterer will unbedingt auf einem T800-Transputer laufen, auf keinem Fall aber auf dem kleinen Brüderchen T414 (bitte Nase rümpfen). Es ist auch möglich, einen ganz bestimmten Prozessor für einen Prozeß anzuwählen (ich möchte unbedingt auf dem ersten Prozessor in der zweiten Reihe von links, ja, dem mit der Nummer 2.1, ausgeführt werden !).

Eine zweite Beschreibung gibt an, welche Hardware vorhanden ist, beziehungsweise, wie die einzelnen Hardware-Komponenten momentan verschaltet sind. An diesem Punkt werden später die Linkswitches veränderbar sein, in der momentanen Helios-Version ist dies aber noch nicht unterstützt. Helios ist ja auch noch nicht ganz fertig. Das Betriebssystem versucht jetzt, möglichst intelligent die Prozesse auf die Hardware zu verteilen. Ein Problem dabei ist, daß kaum zu sagen ist, wieviel CPU-Zeit ein bestimmter Prozeß benötigen wird. Mit etwas Pech werden also genau die Prozesse, die am meisten Zeit benötigen, auf dem gleichen Prozessor ausgeführt.

Leider ist die automatische Verteilung von Prozessen auf parallelen Rechnern noch ein Problem, von dem wir, wie Mr. King erzählte, “nur wissen, daß wir es noch nicht vollständig lösen können”. Dieses Problem ist das Hauptforschungsanliegen bei allen, die sich mit parallelen Rechnernetzen beschäftigen, also auch bei Perihelion Software. Helios ist aber darauf vorbereitet, daß eines Tages Lösungen gefunden werden, die dann sofort in das System übernommen werden können. Das zweite, ganz ähnlich geartete Forschungsprojekt ist die Entwicklung von automatisch verteilenden Compilern. Mr. King: “In ein paar Jahren sollte es Compiler geben, die in der Lage sind, ein Programm automatisch auf ein Prozessor-Netzwerk zu verteilen, genauso, wie wir heute nicht zu wissen brauchen, welche Register ein C-Compiler benutzt Hoffen wir’s.

Helios heute: Die Entwicklungssoftware

Die Version von Helios, die heute (mit den ersten Entwicklermaschinen des Abaq) ausgeliefert wird, trägt die Versionsnummer 0.3; diese Version unterstützt mehrere Prozessoren und ist weitgehend vollständig, allerdings ist sie noch längst nicht fehlerfrei. Auch ein einfacher Fenstermanager wird mit dem Helios-Prototyp mitgeliefert. Dieser Fenstermanager dient dazu, für jede geöffnete Shell ein eigenes Fenster zu eröffnen. Allerdings gibt es bisher noch keine Grafikbibliothek; XWindows wird erst im Juni/Juli fertig sein, eine andere Grafikbibliothek wird es von Perihelion Software voraussichtlich nicht geben.

Mit dem Entwicklungssystem werden auch ein C-Compiler, ein Assembler, ein Make-Utility und diverse Tools, unter anderem ein Debugger, mitgeliefert.

Der C-Compiler ist eine Modifikation eines hochoptimierenden Compilers, der vor 2 Jahren an der Universität Cambridge von A. Norman und A. Microft entwickelt wurde (weshalb er den Namen ‘Norcroft’-Compiler trägt). Der Compiler entspricht dem ANSI C-Standard. Die erste Target-Maschine war der RISC-Prozessor von Acorn, der jetzt die CPU des Archimedes ist. Der Norcroft-Com-piler ist auch der Standard C-Compiler auf diesem Rechner.

Die Code-Generierung des Compilers ist leicht zu portieren, so daß sehr schnell Implementierungen für IBM Mainframe und den Fairchild Clipper entstanden.

Perihelion Software hat die Rechte für den Compiler, soweit es Transputer- und 680X0-Versionen betrifft, gekauft. Versionen für Macintosh, ST und Amiga sind geplant, die Amiga-Version läuft bereits. Über die Geschwindigkeit gibt es Erfreuliches zu berichten: Ohne besondere 68000er-Optimierung soll der Compiler bereits doppelt so schnell wie jeder andere Amiga-C-Compiler sein.

Die Portierung auf Transputer war schwieriger als die Portierung für den 68000. Das liegt daran, daß der Transputer eine Stack-Maschine ist, die keine Register besitzt. Es mußten deshalb auch Änderungen an Compilerstufen vor der Codegenerierung vorgenommen werden.

Für Perihelion Software war es sehr wichtig, die Kontrolle über den Compiler zu haben: “Vielleicht ist der Compiler nicht der schnellste C-Compiler für Transputer, aber er funktioniert und wir haben die Kontrolle darüber. Das ist wichtig, weil wir Helios komplett selbst entwickelt haben, ohne Occam oder das TDS (Transputer Development System, von Inmos, Anm.d.Verfassers) zu benutzen. Wenn man so arbeitet und der Compiler hat einen Fehler, muß man normalerweise warten, bis die Herstellerfirma den Fehler beseitigt. Wir konnten aber Fehler selbst beseitigen und so größere Zeitverluste vermeiden”.

Das Debuggen von Transputersystemen (bzw. überhaupt von Multiprozessorsystemen) ist auch ein noch nicht vollständig gelöstes Problem. Der mitgelieferte Debugger erlaubt es immerhin, jeden beliebigen Transputer zu untersuchen. Es ist ein sogenanntes Wurm-Programm, das sich selbstständig durch das Netzwerk bewegt, bis es am gewünschten Ort angekommen ist.

Natürlich gibt es noch keine Source -Fevel-Debugger, selbst auf PC’s hat es Jahre gedauert, bis Systeme wie Microsoft’s CodeView verfügbar wurden. Es wird allerdings an verbesserten Debugging-Tools gearbeitet. Ein kleines Programm zur Untersuchung der Auslastung der einzelnen Prozessoren ist auch vorhanden, ein echtes ‘Profile’-Tool, das vollständige Performance-Analysen für Prozesse liefert, gibt es natürlich noch nicht.

Es gibt eine vollständige Dokumentation, die auch einzeln für 60 £ erworben werden kann. Bisher sind 4 Bände erschienen, ein Entwicklerhandbuch, ein technisches Handbuch über das Innenleben von Helios, eine Bedienerhandbuch für die Shell sowie das Manual der C-Library. Ein Update-Service ist im Preis enthalten, schließlich verändert sich Helios noch.

Software-Entwicklungen bei Fremdfirmen

Außer der Perihelion-eigenen Software ist aber auch schon eine ganze Menge anderer Entwicklungswerkzeuge bei Fremdfirmen in Arbeit oder sogar schon verfügbar.

Höchste Priorität haben für Tim King C-, Fortran- und Occam- Compiler. C ist wohl die beliebteste Sprache bei den Systemprogrammieren, Fortran hat im technisch/wissenschaftlichen Bereich immer noch eine Spitzenstellung, und Occam ist bisher die einzige Sprache, die konsequent für parallele Programmierung ausgelegt ist. Laut Mr. King erlaubt Occam eine feinere parallele Programmierung, als sie mit den traditionellen Sprachen selbst im Rahmen eines Betriebssystems wie Helios üblich ist. In den ‘alten’ Sprachen tendiert man eher dazu, größere Programmstücke zu schreiben, die dann miteinander parallel laufen können, während es in Occam auch sehr leicht und komfortabel ist, ein paar Zeilen für parallele Ausführung zu schreiben, ohne daß getrennte Prozesse formuliert werden müssen. Natürlich ist es unter einem Betriebssystem wie Helios nicht sinnvoll, Occam mit ‘placed par’-Kommandos zu verwenden. Solche Statements dienen aber auch mehr der Verwendung von Occam auf ‘nackten’ Trans-putem. Aber natürlich kann man jedes Betriebssystem durch im Kontext unsinnige Programmierung durcheinanderbringen.

Fortran wird von der Transputer-Firma Meiko aus Bristol entwickelt, ebenfalls ein Pascal-Compiler. Beide sollen kurz vor der Vollendung stehen; vielleicht sind sie zum Zeitpunkt des Erscheinens dieses Artikels sogar schon fertig.

In Sachen Occam werden im Augenblick zwei Ansätze verfolgt. Zum einen ist die Aachener Firma Parsytech, die eine TDS Source-Lizenz besitzt, dabei, dieses Occam-Entwicklungspaket auf Helios zu übertragen. Inmos selbst entwickelt zum anderen aber auch einen Stand-alone-Compiler für Occam, der ebenfalls unter Helios laufen wird.

Auch Modula II, BASIC (offenbar unvermeidlich !) und BCPL sind bereits bei verschiedenen Herstellern in Arbeit.

Eine ganze Reihe von Softwarehäu-sem versuchen sich an Lisp-Implementierungen, Parsytech verfügt bereits über ein paralleles Prolog, das wohl nur noch an Helios angepaßt werden muß.

Man kann also verhältnismäßig sicher sein, daß für das ATARI Tran-sputer-System, wenn es tatsächlich Ende des Jahres auf den Markt kommt, bereits eine ganze Palette von Entwicklungswerkzeugen verfügbar sein wird. Wenn tatsächlich im Juni auch Maschinen für Anwendungsprogrammierer verfügbar sein werden, darf man bei Auslieferung der ‘offiziellen’ Geräte auch mit ersten Applikationen rechnen, seien es nun Adaptionen von UNIX-Software oder spezielle, neue Software für den Tranputer.

Zum Schluß

Die ATARI Transputermaschine beeindruckt. Nicht nur wegen ihrer Rechenleistung, sondern weil das ganze Konzept durchdacht und flexibel erscheint. Schon jetzt sind viele Erweiterungen verfügbar oder in einem fortgeschrittenen Planungsstadium, obwohl erst 50 Rechner produziert wurden. Auch das Betriebssystem Helios erscheint sehr leistungsfähig und an alle Bedürfnisse anpaßbar. Vor allem das starke Interesse von Drittfirmen beweist, wie gut Helios die Bedürfnisse eines Tranputerrechners erfüllt. Für die Benutzer hat das die angenehme Konsequenz, daß bei Erscheinen des Rechners nicht nur ausreichend Entwicklungssoftware, sondern auch (schließlich heißt das Softwarehaus nicht ATARI) eine vernünftige Systemdokumentation zur Verfügung stehen wird. Die Übertragung bereits existierender Software auf das System wird dadurch erleichtert, daß Unix- und ANSI-C-Bibliotheken zur Verfügung stehen, auch das Fenstersystem XWindows, das ja ebenfalls ein internationaler Standard ist, bürgt für schnell verfügbare Software. Die einzige Frage, die offen bleibt: Wann kann man endlich so einen Rechner kaufen???

cs

XWindows

Xwindows, abgekürzt einfach X ist ein netzwerkfähiger Fenstermanager nach dem Client/Server-Modell. Entstanden ist das System seit 1984 am Massachusetts Institute of Technology (MIT), wo für verschiedene Netzwerkanwendungen (Projekt Athena genannt) ein Fenster-System benötigt wurde. Seit der ersten Vorstellung sind eine Reihe von Versionen vorgestellt worden, die letzte, gerade erst erschienen, trägt die Versionsnummer 11. Diese Version, mit vollem Namen XWindows XI 1.1, ist auch die erste, deren Kommunikationsprotokolle für längere Zeit den Standard des X-Systems bilden soll.

Xwindows ist weit verbreitet, weil das MIT die Software nicht verkauft, sondern gegen einen Unkostenbeitrag als Public Domain weitergibt. Damit dürfte X die umfangreichste Public Domain Software sein, die es je gegeben hat. X läuft auf Workstations von Apollo bis Sun. auf VAX Minicomputern und auf den verschiedensten intelligenten Terminals für Großrechner. X hat sich in den vergangenen Jahren immer mehr als Standard etabliert.

X ist netzwerkfähig. Das bedeutet, daß X in der Lage ist, mehreren Teilnehmern in einem Netzwerk kontrollierten Zugang zu einem oder auch mehreren Rasterbildschirmen zu erlauben. Auch mehrere hundert Workstations können so kontrolliert Zusammenarbeiten, ohne daß auf den Bildschirmen der Benutzer Chaos entsteht. Auch Eingabegeräte wie Tastatur. Maus und Scanner können unter X kontrolliert werden.

X arbeitet nach dem Client/Server-Modell. X stellt also Server zur Verfügung, die die angeschlossene Hardware steuern. Mit diesen Servern kann ein Client, also ein Anwenderprogramm, kommunizieren, indem es eine Nachricht an den Server schickt, auf die der Server dann reagieren bzw. antworten kann. Dabei kann der Server ohne weiteres auf einer anderen Maschine als der Client installiert sein. Mit diesem Mechanismus paßt X geradezu perfekt in die normale Infrastruktur eines auf Mitteilungen basierenden Betriebssystems wie Helios.

X ist mit über 13 Megabyte Sourcecode ein großes System. Durch die gewünschten Fähigkeiten zur Zusammenarbeit in einem Netzwerk muß vieles umständlicher gelöst sein, als in einem Einprozessorsystem. Der X-Programmierer ‘sieht’ von X nur eine riesenhafte Bibliothek, die Prozeduroder Funktionsaufrufe in Mitteilungen an einen X-Server verwandelt. Diese Bibliothek darf man sich aber nicht wie ein komplexeres GEM vorstellen, auch wenn einige Elemente einer Grafikbibliothek wie GEM ein wenig ähneln.

Der Fensterbegriff unter X ist sehr weit gefaßt. Ein Fenster ist einfach ein rechteckiger Bildschirmausschnitt mit einer Umrandung, die null oder mehr Pixel breit sein kann. Auch ein Bildschirmhintergrund usw. kann für jedes Fenster definiert sein. Der Bildschirm in seiner Gesamtgröße stellt das sogenannte ‘Rootwindow’ dar, zu dem alle weiteren Fenster relativ angegeben werden. Jedes Fenster hat sein eigenes Koordinatensystem. Eine Applikation kann sich auf dem Bildschirm also Fenster als beliebige Baumstruktur anlegen, ähnlich der Resource-Struktur im GEM. Normalerweise sollte eine Applikation aber nicht direkt X aufrufen, sondern nur über einen sogenannten Toolkit, der komplexere Funktionen zur Verfügung stellt. Die sogenannten Low-Level-Aufrufe von X sollen im allgemeinen vom Toolkit durchgeführt werden.

X beinhaltet keine Benutzeroberfläche oder auch nur Elemente dazu, wie z.B. den GEM-Desktop oder die verschiedenen Objekttypen für Resourcen. Diese Funktionen müssen auf X aufbauend in Form eines Toolkits oder einer X-Erweiterung implementiert wetrden. X beinhaltet also ‘nur’ das Rohmaterial, das die freie Gestaltung von Benutzeroberflächen in einem Netzwerk mit vielen Clienten erlaubt.


Aus: ST-Computer 06 / 1988, Seite 21
Links
Copyright-Bestimmungen: siehe Über diese Seite