[Amiga][Down] [Scene] {}
 
[Special] 

| PPC Special | PPC Tutorial |
 
 

[Cover]
[Editorial]
[Inhalt]
[News]
[Hardware]
[Software]
[Workshop]
[Spiele]
[Special]
[Feedback]
[Etc]


To Warp or Not To Warp

 

Die Systemintegration des PowerUp in das Amiga OS


Der PowerPC verspricht Leistung ohne Ende. Doch was hilft die Leistung, wenn Sie brachliegt. Ein ausgeklügeltes System ist notwendig, um das Potential der Power CPU auch zu nutzen. Wie das neue Herz in das bestehende Amiga System integriert wurde, lesen Sie hier.

Der PowerPC auf der Cyberstorm (und den Blizzard PPC Karten) arbeitet parallel zur ebenfalls am Board befindlichen 68K CPU. Beide Prozessoren können alle Resourcen des Amigas benutzen. Zum Betrieb des PowerPC ist es aber unbedingt notwendig, RAM auf der Cyberstorm zu installieren. Dieses RAM muß paarweise installiert werden, weil der PowerPC mit 64 Bit darauf zugreift. Der PowerPC selbst kann aber sogar ins ChipRAM schreiben und davon lesen! Allerdings mit starken Perfomance-Einbrüchen. Seine wahre Performance zeigt der PPC im Memtest in das FastRAM. Phase5's eigener Memtest weist einen Durchsatz von 138MB/sec ins FastRAM (60ns - FastPageMode Standard PS/2 SIMMs, m. 604e/180) zu vergleichsweise niedrigen 68MB/sec des 68060/50. Ein 200MHz 604e kommt auf geringfügig höhere Werte als die 180MHz Version.

Laufen beide Prozessoren parallel, kommt es durch die gemeinsame Nutzung des RAM-Interfaces zu einem Geschwindigkeitsverlust, der meistens aber nicht merkbar ist. Im Rendertest mit lwShow (LightWave-Show zum Anzeigen von Lightwave Objekten mit CyberGL) bekam ich beim Netzwerkzugriff auf den Amiga Timeout Fehler, wenn nur der 68060 benutzt wurde. Rendert hingegen der PowerPC, kann parallel noch voll über das Netzwerk auf den Amiga zugegriffen werden, ohne das der Socket in die Knie geht.

Nachdem das Betriebssystem nichts von der fremden CPU weiß und diese nicht direkt nutzen kann, mußten sich die Entwickler etwas einfallen lassen. Herausgekommen ist ein Minibetriebssystem, daß auf der PowerPC CPU und der 68er CPU parallel läuft und die Verbindung zwischen AmigaOS und PPC herstellt. Hier zeigt sich eindrucksvoll die Flexibilität des AmigaOS. Die Schnittstelle ist komplett als shared library implementiert und kann von jedem Programm genutzt werden - ist also nicht abhängig von der Programmiersprache. Das PPC-Betriebssystem sorgt für den Austausch von Nachrichten mit dem AmigaOS (Messages) und verwaltet den Speicher für den PowerPC. Außerdem sorgt es dafür, daß PowerPC-Programme parallel laufen können (scheduler, multitasking auf dem PPC - parallel zum AmigaOS Multitasking).

Im Detail gibt es allerdings hier zwei verschiedene Ansätze von Haage&Partner (H&P) und Phase5. Ich möchte gleich vorweg sagen, daß mir persönlich die Haage&Partner Lösung besser gefällt. Sie ist meiner Meinung nach eine bessere Integration in das Amiga Konzept - allerdings auch mit Nachteilen die ich nicht verheimlichen möchte.

Aber zuerst zu den Grundlagen, zur Integration der ppc.library(Phase5) bzw. des WarpOS (H&P). Wie schon erwähnt setzten beide Lösungen eine Art Minikernel, ein Minibetriebssystem ein, das über ein ausgeklügeltes Nachrichtensystem Daten und Anweisungen von einem Prozessor zum anderen weiter leitet. Beide Teile arbeiten vollkommen asynchron, der 68er Teil läuft also parallel zum PowerPC-Teil. Will man nun PowerPC Code benutzen, muß man zuerst ein PowerPC Programm oder Programmmodul erstellen. Das wird dann in den Speicher des Power PC "geladen" und eine Anweisung teilt dem PowerPC Betriebssystem mit, daß das Programm an der Stelle xy ausgeführt werden soll. Hier unterscheiden sich dann wieder die ppc.library (von Phase5) und das WarpOS von Haage&Partner.

[WarpUp?]

Die ppc.library benutzt ein eigenes Binärformat, daß auf anderen PowerPC Platformen üblich ist: das ELF Format. Dieses ist Konzeptbedingt inkompatibel mit dem Hunk-Format des Amigas. Man könnte auch sagen, das Hunk Format ist überholt. Das ELF Format hat den Vorteil, daß man "handelsübliche" Compiler aus der Workstation Welt benutzen kann, um PowerPC Code zu erzeugen. Der GNU C Compiler für den Amiga wird beim Erwerb der Cyberstorm auf CD mitgeliefert, seit kurzem gibt es im Aminet den Freware Compiler vbcc, der ebenfalls ELF Programme erzeugen kann. Das Problem am ELF Format ist, daß man ein Modul nicht einfach auslagern und vom 68000er als "Subroutine" anspringen kann, da es tatsächlich ein eigenständiges Programm ist. Dieses Programm wird dann von der ppc.library auf die PPC CPU "downgeladen" und bei Bedarf mit einer Funktion "RunPPC" der ppc.libray aufgerufen. Selbstverständlich ist es möglich, dieses ELF Programm als Binärdatei in den 68K Teil zu linken, und diesen Teil dann dem PPC zugänglich zu machen. Ein "Programm" an sich ist also nicht zwingend erforderlich. Ich möchte deshalb darauf hinweisen, weil Haage&Partner hier einen anderen Weg geht.

Der StormC-PPC Compiler benutzt für den PPC Code nach wie vor das Amiga-Hunk Format. Der Vorteil dabei ist, daß gewöhnlich bestehender Code durch einfaches neucompilieren in PowerPC "umgewandelt" werden kann. Das Programm kann weiter voll auf Amiga Systemstrukturen und Resourcen zugreifen - was in dieser Art und Weise mit dem gcc von Phase5 nicht möglich ist. Shared Variablen zwischen 68er und PPC CPU sind nur mit dem StormC möglich - das erfordert auch keinen Context-switch, da auf ein und die selbe Adresse im Speicher von beiden CPUs zugegriffen werden kann - das geht mit dem gcc auch, aber mit sehr viel mehr Aufwand. Der Nachteil dieser Methode - und der auch das ELF-Format rechtfertigt: Systemstrukturen sind oft nicht auf Langwort Adressen ausgerichtet, der gcc kann Strukturen nur an Langwortadressen ausrichten, der vbcc kann auch so "umgeschalten" werden, daß auf Amiga-Systemstrukturen zugegriffen werden kann. Für eine moderne RISC CPU sind byte aligned Speicherzugriffe (ungerade Speicheradressen, auch auf WORD boundaries) der Performance Tod!

Andererseits ist es nicht wirklich so tragisch. Das ELF Format wurde dahingehend optimiert, um durch Langwortausrichtung das Pipelining der PowerPC intensiv nutzen zu können. Durch ungerade Adressierung kann es zu ineffizienter Ausnutzung der parallel Abarbeitung der Befehle in der PowerPC CPU kommen. Eine geringere Leistung ist die Folge. Auf der anderen Seite hat das AmigaOS ein Fülle von solchen "Alignment"-Verletzungen. Auch eine neues OS kann diese aus Kompatibilitätsgründen nicht einfach "gerade" biegen, darum kommen wir nun mal nicht herum. Für einen guten Programmierer sollte es nicht zu schwierig sein, sich auch mit dem StormC an die Alignment-Kriterien zu halten.

Mandelbrot BIG
Mandeldemo
1024x768, 130K

Mit dem StormC ist es sehr einfach, schnell bestehenden Code in PowerPC Code umzuwandeln. Oft reicht ein einfaches Neucompilieren. Ich bin zum Testen dieser Technik den umgekehrten Weg gegangen. Das Mandeldemo, daß gemischten PowerPC/68K Code benutzt (zu diesem Thema kommen wir noch) wurde in ein reines 68K Programm umgebaut. Es beinhaltet also nur Amiga Funktionsaufrufe und Standard Ansi C Funktionen. Daraus wurde ein 68060 optimiertes Mandelbrotprogramm erstellt. Ich habe mir erlaubt, nur einen 8 Bit Modus mit 256 Farben einzubauen - allerdings mit einer shared Palette und es wird in ein Intuitionwindow gezeichnet. Dieses Detail ist wichtig, da dieser Teil verhältnismäßg viele Betriebssysteaufrufe beinhaltet. Wenn der PPC einen Betriebssystemteil aufruft, kann dieser nur im 68000er Modus ausgeführt werden, d.h. das Programm muß vom PowerPC in den 68K Modus wechseln, ein sog. Context-Switch ist notwendig. Dieser kann in Prozessorzeit eine kleine Ewigkeit dauern - bis zu 2.5 ms.

Das Mandelbeispiel läßt sich mit dem StormC Compiler durch einfaches Umschalten der Ziel-CPU in den Compilereinstellungen von 680x0 auf 603 bzw. 604 und durch ersetzten der amiga.lib gegen die ppcamiga.lib neu compilieren. Durch das simple Neucompilieren erreichen wir einen Steigerung der Rechngeschwindigkeit um den Faktor 8-12! Der Start des Programms wird allerdings ein bißchen "verzögert". Hier möchte ich wieder das Detail von zuvor aufgreifen. Die "shared Palette" (also ein gemeinsamer Farbraum) wird anfangs in einer Schleife mit 256 Durchläufen berechnet. Pro Schleifendurchlauf wird die Betriebssystemfunktion ObtainBestPen() aufgerufen, im PowerPC-Programm also ein Contextswitch ausgeführt. Dieser Teil braucht in der PowerPC Version länger als in der 68K Version - allerdings nicht unbrauchbar länger. Durch geschickte Code Optimierung kann der Teil mit hohem Anteil an System Code ausgegliedert und als 68000er Code implementiert werden. Ein Mixed Binaries, also Code in dem 68000er und PowerPC Teile vor kommen, ist machbar.

[Mandelbrot Medium]
Mandeldemo
800x600, 80K

Hier kommen wir wieder zurück zum Verfahren von Phase5. "Mixed Binaries" in dieser Form sind mit Phase5's Lösung nicht möglich, jedoch ähnelt die Vorgehensweise doch dem des gemischten Codes. Statt einen Funktionsaufruf wird über die ppc.library in das ELF-"Programm" gesprungen. Prinzipiell wird das vom StormC nur versteckt, der Programmierer "sieht" nur einen Sprungbefehl in ein Untereprogramm.

Führt man die Idee von Haage&Partner noch einen Schritt weiter, erkennt man aber Vorteile. Prinzipiell ist nicht definiert, wie ein PowerPC Programm 68K-Teile aufruft. Man könnte vielleicht in Zukunft hier einen 68000er Emulator einsetzten statt einer eigenen CPU (Man denke an PPC Laptops). Außerdem sind unter WarpOS Mixed Libraries möglich, deren Funktionen auch als PowerPC native Code vorliegen. Ruft ein PowerPC Programm nun eine Funktion einer solchen Bibliothek auf, wird diese ohne Contextswitch, also mit voller Performance, ausgeführt. Könnte man das mit Systemcode machen (kann jedoch nur der machen, der die Sourcen des Systems besitzt, also AI), kann man das Betriebssystem schrittweise native für den PowerPC portieren. Das ist allerdings nur ein Gedankenmodell und wird wohl (leider) in dieser Form nicht realisiert werden. Ich meine aber, daß man dadurch die unterschiedlichen Philosopien zwischen WarpOS und ppc.library erkennen kann. Die ppc.library ist ein Steuerschnittstelle für PowerUp Karten, WarpOS ist eher eine Migrationsschnittstelle. Was sich schluß endlich durchsetzen wird, wird die Zeit zeigen. Womöglich geht AI ganz andere Wege, wir werden sehen.

WarpMandel
[Source]
Download 70K

Zum Schluß bleibt mir nur zu sagen, daß mit dem PowerUp der erste wichtige Schritt getan ist, um rechenintensive Programme wieder auf den Amiga zurück zu bringen. Als Nebeneffekt erhält man neben den PowerPC ja auch noch eine schnelle 68K CPU zu einem vernünftigen Preis. Diese ist für die Bedienung des Amiga (derzeit) noch ausreichend, der PowerPC kann in Bereiche, wo Zeit gleich Geld ist, den Amiga wieder attraktiv machen (z.B. in der Bildbearbeitung und zum Rendern). In einer späteren Ausgabe möchte ich noch einen Schritt tiefer in die Systemintegration des PowerUp einsteigen, eventuell auch in Form eines Workshops. Für diese Ausgabe sollte der Ansatz und die grundlegenden Unterschiede zwischen WarpOS und ppc.library aber ausreichend erklärt sein um beide Systeme vorzustellen.


Jürgen Schober ...........


- Phase5
- Haage&Partner
- PowerPC Mandel Screenshot, 1024x768, ca. 130KB
- PowerPC Mandel Screenshot, 800x600 - skaliert, ca. 80KB
- PowerPC/68K WarpMandel StormC-Projekt, ca. 70KB
 
[Up] .... {}