|
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.
|
