|
Wir wollen an dieser Stelle nicht in die Details der Programmierung einsteigen;
hierzu gibt es weitere Informationen in den Entwicklerunterlagen, Libraries
und Autodocs sowie den von phase 5 bereitgestellten Beispielen. Es
hier zusammenfassend den prinzipiellen Ansatz zur strukturierten Entwicklung
für PowerUP-Systeme erörtert werden.
Wesentlich bei der Umsetzung von Software für PowerUP-Systeme ist
eine konzeptionelle Richtlinie, die phase 5 allen Entwicklern empfehlen. Diese
sieht vor, Programme bei der Umsetzung für PowerUP (und damit auf einen
neuen Prozessortypen) strukturiert zu überarbeiten, soweit die Quelltexte
der Entwickler nicht bereits entsprechend strukturiert sind.
Um eine optimale Nutzung der Hardwareleistung und eine optimale Zukunftsoffenheit
zu gewährleisten, wird dazu empfohlen, Programme in modularer Form
in Sub-Tasks aufzuteilen, die wir im folgenden Threads nennen, denn dieser
Ansatz entspricht dem Multi-Threading (eine Technik, wobei ein Task weitere
Subtasks für verschiedene Aufgaben erzeugt). Es wird an dieser Stelle
bewußt nicht auf Details zur Speicherverwaltung bzw. zum Speicherschutz
in Multithread-Systemen eingegangen, da diese abhängig sind von den dafür
im Betriebssystem vorgegebenen Möglichkeiten; es sei nur erwähnt,
daß auch das in der PowerUP System Software implementierte Multithreading
auf Speicherschutz vorbereitet ist und Applikationen, die unter der PowerUP
System Software laufen, bei einer entsprechenden Änderung des OS sofort
speichergeschützt arbeiten könnten.
Diese Threads können nach Wahl des Programmierers auf 68k- oder
PowerPC-Seite laufen. Die asynchrone Kommunikation wird über das von
uns implementierte Message-System durchgeführt,
über das die verschiedenen Threads Signale, Messages und Daten austauschen.
Eine sinnvolle Implementation dieses Prinzips besteht beispielsweise darin,
einen Haupt-Task unter 68k zu erstellen, mit dem auf der aktuellen PowerUP-Implementation
das Programm gestartet wird, und in dem z.B. das User-Interface eines Programms
aufgebaut und alle damit verbundenen (zur Zeit 68k-basierten) OS-Aufrufe
ausgeführt werden. Dieser Haupttask erzeugt die zur Durchführung
bestimmter Aufgaben benötigten Threads. Ein asynchroner File-I/O könnten
z.B. als 68k-Thread implementiert sein, die Durchführung einer Filtermatrix
auf eine 24-Bit-Grafik als PowerPC-Thread. Sendet z.B. in letzterem Beispiel
der Haupttask ein Signal zum Thread, der die Matrixoperation durchführt,
kann der Haupttask währenddessen weiterarbeiten und z.B. auf weitere
Eingaben des Anwenders reagieren oder sonstige Aufgaben erledigen; der PowerPC-Thread
sendet nach Erledigung seiner Aufgabe ein Signal zurück an den aufrufenden
Task, so daß dieser dann sofort mit der weiteren Verarbeitung der
Daten fortfahren kann (wie z.B. diese in ein Ziel-Fenster auf der Oberfläche
zu kopieren). Selbstverständlich können Threads auch Signale und
Daten mit anderen Threads austauschen.
Durch eine solche Vorgehensweise erreicht die auf PowerUP-Systeme portierte
Software eine optimale Nutzung der Multiprozessorfähigkeit; wenn z.B.
in dem oben genannten Beispiel der Haupttask einem Thread per Message die
Aufgabe zuweist, eine 30 Sekunden dauernde Bildmanipulation vorzunehmen,
muß der Anwender nicht darauf warten, daß der Busy-Anzeiger
verschwunden ist, sondern kann problemlos weiterarbeiten. Ebenso kann der
Programmierer bereits heute abfragen, wieviele Prozessoren im System vorhanden
sind, und eine kleine Routine einbauen, die bei mehreren Prozessoren die
zu bearbeitenden Daten aufteilt und einfach mehrere Kopien des zur Bearbeitung
nötigen Threads erzeugt, die die PowerUP System Software dann auf die
vorhandenen Prozessoren verteilt. Damit können Entwickler bereits heute
mit voller Unterstützung von Multitasking, Multithreading und Multiprozessorfähigkeit
entwickeln.
Darüber hinaus erlaubt diese Vorgehensweise in Kombination mit der
implementierten Multiprozessorfähigkeit
auch das zukünftige einfache Einbinden von innovativen Hardware-Produkten
in das System, bei ebenso einfacher Unterstützung durch bestehende
Software-Anwendungen. Es ist für Hardware-Entwickler beispielsweise
möglich, eine High-End-3D-Hardware oder einen Spezial-DSP für
Multimediafunktionen als Erweiterungsprodukt - z.B. als Zorro-Karte oder
als per Ethernet angeschlossenes Subsystem - zu entwickeln, auf diesem einen
bestimmten Funktionsumfang (z.B. eine GL-Implementation oder eine MPEG/JPEG-Engine
mit allen notwendigen Funktionen) zu implementieren, und für diese
Erweiterung einen Message-Port und die jeweils benötigten Messages
zu definieren. Dem Hersteller z.B. einer 3D- oder Multimedia-Software, die
das Message-System der PowerUP System Software verwendet, muß lediglich
der Name des Message-Ports, der zur Verfügung stehende Funktionsumfang
und die dafür verfügbaren Message-Typen dokumentiert werden, um
die Funktionen der neuen Hardware ohne Probleme innerhalb seiner Applikation
nutzen zu können.
Durch das Multithreading-Prinzip, das im übrigen in keiner Weise
einer Amiga-Konformität widerspricht,
wird auch in Hinblick auf die Zukunftskompatibilität ein weiterer Vorteil
für Software-Entwicklungen erreicht. Durch die von phase 5 empfohlene klare
Trennung von 68k-basierten Programmteilen und PowerPC-basierten Programmteilen
können bei einer späteren Weiterentwicklung des AmigaOS die OS-basierten
(also zur Zeit als 68k-Teil implementierten) Teile leichter ausgetauscht
oder upgedatet werden. Werden z.B. PowerPC-native Grafikfunktionen integriert,
so lassen sich bei klarer Strukturierung die alten Betriebssystemaufrufe
leicht durch die neuen ersetzen - vor allem dann ein Vorteil, wenn die neuen
Aufrufe anders strukturiert oder erweitert sind. Es wird in diesem Ansatz
eine wesentlich bessere Ausrichtung auf zukünftige Anforderungen, als
in einer Verquickung von aktuellem 68k-Code (inklusive aktuellen OS-Aufrufen
und Funktionen) mit dem neuen PowerPC-Code gesehen. Auf diese Weise wird Entwicklern,
die heute für PowerUP Software entwickeln, die Sicherheit gegeben, daß
die weiterentwickelte Software leicht portierbar, weitestgehend hardwareunabhängig
und auch auf größere Updates und Veränderungen des Betriebssystems
vorbereitet ist, welche bei einer Weiterentwicklung des AmigaOS als
sinnvoll und notwendig erachtet wird.
|
