Die empfohlenen Richtlinien zur Umsetzung von Software für PowerUP

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.




zurück zur Übersicht zum Seitenanfang


phase5


Diese Seite ist Copyright © 2005-2017 bei Matthias Münch. Alle Rechte vorbehalten.
Einige Inhalte unterliegen dem Copyright von phase 5 digital products.
Amiga, AmigaOS und das Amiga-Logo sind eingetragene Warenzeichen von Amiga Inc.
PowerPC und das PowerPC-Logo sind eingetragene Warenzeichen der IBM Corporation