Recommended Guidelines for the implementation of PPC software on PowerUP systems

We will not cover programming styles here in detail; there is quite a lot of documentation out there on this topic in the phase 5 developer notes, the libraries and autodocs as well as the various examples provided by us. We will just discuss the basics to structured development under PowerUP.

Most important for porting software to the PowerUP is a conceptual guideline which phase 5 recommends to all developers. When porting or optimizing software to/for PowerUP (which effectively also means working on a completely new processor type) it is recommend that the the developers structure their software programs internally, if they havnt already done so.

To gain optimal perfomance out of the hardware design currently available and to secure an open design to future developments, we recommend the use of modular program structures by using sub tasks, which we call threads subsequently, because our approach is equivalent to multi-threding (a procedure where tasks create subtasks for different jobs). We are not covering details on memory allocation or memory protection for multi threaded systems in this description, because this is very much dependant on the options available from the operating system. The multi threading mechanisms implemented in the PowerUP system software are already prepared for memory protection, and as soon as it is implemented in the operating system, applications using the PowerUP system software benefit automatically from the memory protection.

The programmer can choose for all threads whether they should use the 68k or the PowerPC CPU. The asynchronous communication is handled fully transparently by our message system, which is used to exchange signals, messages and data between the different tasks. An efficient policy is for example to design a 68k master task which is used in the current implementation of PowerUP to start up the program, that handles the user interface and all related OS calls which are currently 68k based. This main task subsequently creates the threads required for the various jobs. Asynchronous file I/O operations for example may be implemented as a 68k thread while applying filter operations to a 24 bit graphics runs as a PPC thread. In this example, the 68k main thread sends a signal to the PPC thread and can continue to act on user input. The PPC thread sends back a signal upon completion of the filter operation to the controlling 68k thread which continues to act on the results, e.g. by copying the graphics data to a destination window. Of cours subthreads can communicate to other subthreads without intervention of parent threads.

This implementation enables any application to automatically benefit from multi-processor designs. If for the above example the main thread instructs a subthread to work on an image manipulation operation which takes 30 seconds, the user does not need to wait for the busy pointer to disappear, but he can work on. In addition the programmer can ask the system for the number of CPUs present on the system and use this information to launch multiple identical sub threads, which are dispatched to different CPUs by the PowerUP system software, and which all execute a certain part of a complex operation. This enables programmers today to actually develop software which is prepared to use multitasking, multithreading and multiprocessing.

In addition this proposed procedure in combination with the implemented multiprocessing capabilities allows easy implementation of future developments of innovative hardware whith easy support by existing applications. So it is possible for developers to be prepared to use for example high end 3D hardware or special DSPs for multimedia operations as expansion products which can be implented as Zorro III boards or even be connected via a local network and incorporate special functions, like a GL implementation or a MPEG/JPEG engine. All they will need to use this is to define a message port and the necessary message data structure. The vendor of a 3D or multimedia application that uses the PowerUP message system only needs to know the message port name, the function set and the message types to be able to fully use the extended hardware.

The multithreading system, that does not conflict with the Amiga OS philosophy, will be of advantage concerning future compatibility for software applications by taking advantage from the strict distinction of PowerPc and 68k based code segments, since for future OS developments the currently 68k based code parts can be easily replaced or updated. If for example the 68k based graphics calls will be replaced by a PPC native graphics system, the 68k library calls can be easily replaced by PPC calls for structured applications, especially if those new calls need a new structure or have extended functionality. We think this approach has a much better focus on any possible future development than any mixed binary solution that requires lots of context switches and may lead in addition to a lack of structured task dispatchment. By proposing our solution we give the developers, who develop with and under PowerUP, the security that applications will be easy to port, mostly hardware independend and prepared even for major changes of a possible future operating system, which we consider as important for the future development of the Amiga.

back to Overview back to Top


This page is Copyright © 2005-2023 by Matthias Münch. All Rights reserved.
Some content is under Copyright of phase 5 digital products.
Amiga, AmigaOS and the Amiga-Logo are registered Trademarks of Amiga Inc.
PowerPC and the PowerPC-Logo are registered Trademarks of the IBM Corporation