As the developer of the StormC developer-environment it has always been our aim to support all significant new Amiga-developments. Our philosophy is to place in the hands of the developer a tool that enables him to achieve the best result with the minimal effort possible. The first step in this direction was demonstrated with the introduction of StormWIZARD for AmigaOS and p.OS and with the p.OS-support of StormC. Developers that use StormC and StormWIZARD are able to easily maintain a common appearance and version of their software on both platforms. From the economic point of view this is a very important factor. Supporting an alternative operating system on the same CPU is one thing - supporting a new type of CPU is a completely different and much more complex matter.

In about 2 years of development we have taken the next step and completed a hardware-independent PowerPC-interface. This interface, called WarpUP, was first presented to the public on Sep 26, 1997 on our homepage and on Sep 28, 1997 at the Amiga-meeting in Hof, Germany. Shortly before that, on Sep 26, our solution was presented to Phase 5 because we were and are of the opinion of having made a valuable contribution to supporting the PowerPC-platform. Phase 5, however, did not seem to be of this opinion and published a very emotional statement on Sep 28 in which they announced to cease any developer support for us and called WarpUP and our StormC compiler "unusable".

However, reactions like that of Phase 5 are very unproductive. They bring disorder to the Amiga-market that has just been revived and they help neither Amiga-producers, nor Amiga-users. The attacks by Phase 5 on our WarpUP-package are in our opinion an ill-considered over-reaction. As opposed to the statements made by Phase 5, our package contains a solution that is compatible to that of Phase 5, as well as an alternative that completely replaces the Phase 5 software. The user is given the full freedom of choice - whichever approach he prefers, he can use. The compatible solution was known to and tolerated by Phase 5 at all times. Therefore it comes as even more of a surprise that Phase 5 now announce to cancel any further support and to intentionally make future PowerUP-boards incompatible to our software.

Instead of entirely shutting out a software-solution, the user must be given the opportunity to make his own experiences with either software and discuss the advantages and disadvantages of both approaches in a reasonable way. Whoever denies this freedom of choice acts in a dictatorial manner in order to protect himself from any competition.

We offer all interested users and developers information on our developments. The complete archive that includes a number of demo programs (that also run on 68K-Amigas that has an 040 or better) and full documentation is available free of charge from our FTP-server. Everybody is welcome to judge WarpUP for himself. Our development shows in an impressive way that is not necessary to create a new executable-format or a way to dynamically link libraries. From its very beginning, he Amiga operating-system has offered all features that are necessary to support a new type of CPU - be it with or without an additional 68K-CPU present in the system.

The notes Phase 5 made regarding such new techniques for new OS-versions must invariably betray to the attentive reader the plans of Phase 5 of dropping AmigaOS in the near future in favor of their own development. What should not be forgotten is that the rights for further development of the Amiga operating system are held by Amiga International who will surely not surrender these rights in favor of a deviating approach.

In the midst of this necessary discussion about a standardized interface between the PowerPC and AmigaOS one should never forget that it is the users who keep the Amiga alive - not a single hard- or software company. At the end of this discussion, the closing statement has to be:

"And the winners are: The Amiga-users"

In the following document we will provide you with a deeper and more technical insight in the course of our development of WarpUP and StormC for the PowerPC.

The development history of WarpUP

Nearly two years ago, at the Computer '95 show in Cologne, Amiga Technologies announced new Amiga models that were to be based on the PowerPC-CPU. At the same time, Phase 5 also made first announcements of their PowerPC-boards for all Amiga-models available in the market. This caused us to decide to make our developer-system PowerPC-compatible.

The development of StormC-PowerPC commenced in March 1996, right after the CeBit. The concepts we set up at that time were intended to stick as tightly to the Amiga operating system as possible which didn't pose a problem at all. For this reason, we never even had the idea of using a different executable-format, even less without a official decision of the copyright-holder to the operating system. Our concept was also designed to enable us to quickly react to any possible changes to the OS and its application interface in order to save software-developers as much conversion work as possible.

Unfortunately, the Amiga got into financial trouble yet again, a situation that, contrary to what the Amiga-users and -developers were led to believe, was not (and probably could not be) solved by Viscorp. Further development of the operating system as well as the long-awaited construction of a PowerPC-Amiga did not happen. What also remained missing was the definition of an interface for Amiga PowerPC-applications. However, we did not let ourselves be put off by this and kept developing in an Amiga-compliant way, as our solution did not mandate nor assume a change to the existing operating system.

When Phase 5 announced that they would be building a dual-processor-board that would have a 68K and a PowerPC run in parallel, it became an urgent necessity to support the so-called Mixed-Binaries. This type of program contains 68K- as well as PPC-code within one and the same program.

In the most optimal case it is completely irrelevant to the programmer which parts of a program are present in which type of code. Access to data (e.g. global variables) can be made by both CPUs without problems and a switch from one CPU to the other is done fully automatic, without any additional programming.

The developer only decides which part of the program should best be run on the PPC (e.g. the raytracing-core or the conversion functions for graphics formats, etc.) and which parts are to remain on the 68K (e.g. everything regarding the graphical user interface). In this context it should not really matter if the code-parts are tightly interwoven, i.e. common variables and data structures are used, return jumps from one part to the other are made via so-called function pointers, etc.

Much to our surprise, Phase 5 chose to use the ELF format which makes generating the necessary Mixed-Binaries (which are even recommended by Phase 5) a pain for the programmer:

• The PPC part of the program must be loaded manually;
• It is not possible for the CPUs share global variables;
• Data structures are interpreted differently by current 68K compilers than they are interpreted by GNU-C for the PPC, therefore these structures can not be shared between the CPUs;
• Return jumps via function pointers and even "normal" switches between the CPU must be programmed manually.

When adding this up, you end up with a very long way when porting an existing AmigaOS program to the Phase 5 solution. As you might know, select developers have had access to special PPC developer-boards for almost a year - the fact that no application of significant size could be ported as of yet clearly indicates the problems involved in the approach required by Phase 5.

After almost 18 months of development, WarpOS and StormC now offer the optimal way to create Mixed-Binaries. The developer breaks down his program into a 68K- and a PowerPC-part, in the most simple case by choosing which of the program modules (C source codes) should be compiled for which CPU, in the most difficult case by breaking each program module down into two new modules (one each for the 68K- and PPC-code). After that, only a recompile is necessary and there you have a your new PPC-program. StormC and StormLink take care of everything else. A single executable is generated from the 68K- and PPC-parts - this means that no PPC-parts have to be loaded at a later point during program execution. Due to the shared access to global variables and the compatible interpretation of the data structures by the 68K- and PPC-code, not a single line of source code needs to be changed. Context switches between the CPUs are generated automatically - the programmer doesn't even need to know when exactly these switches occur.

In the middle of October '96 Phase 5 finally provided us with two PowerPC developer-boards and a very rudimentary software-interface to the PowerUP-board. Despite the simplicity of this software interface it was already so different from our (and thus: the Amiga-compliant) approach, that from the very start of the actual development we had to go our own way. Phase 5 was fully informed about what we were doing. Our way was not the one proposed by Phase 5, but it was a possible and flexible way and at that point Phase 5 did not make any objections.

At the Computer '96 we were already able to present our first developments done with StormC and StormPowerASM. These developments were based on the tried-and-tested Amiga hunk-format and worked flawlessly.

Under real-life conditions it soon became apparent that the performance of the PowerPC could not be noticed as much as we had expected - this was due to the complicated way that was necessary to handle AmigaOS-calls - which was in turn caused by the dual-processor technology employed by Phase 5. For every function call it is necessary to execute a context switch to the 68K CPU, execute the 68K system-function and finally switch back to the PowerPC-program with another context-switch. Upon every switch it is of course necessary to flush the data cache which takes a tremendous amount of time. The way we see it, it would have been possible to speed up the context-switches by extending the hardware. Phase 5 would not hear anything of that, though - a fact that surprised us quite a bit. At the same time we asked to be given more information on the hardware in order to help with the problem. This plea for information was rejected with the explanation that Phase 5 could make changes to the hardware at any time, so that our solution would not work anymore. Software that was directly adapted to the hardware would then not work anymore. Only for their very own software would it be guaranteed that an adaptation could be made in a very short time. For us as a software-developer this was very dissatisfying answer since it only told us that the software-side of the PowerUP board was to be held under monopolistic control in order to keep competition away.

At that point in time we already suspected that Phase 5 would use these arguments to force any unwanted developments out of the market without discussion. For this reason we are not too surprised about the draconian measures Phase 5 announced they will be taking against our WarpUP software.

It was the December of last year when our developer-team, above all Sam Jordan an Michael Rock, created a solution that drastically improved the context switches compared to the Phase 5 solution. It was already in January 97 when we had a very stable extension to the Phase 5 software that achieved a context-switching time of 0.5 milliseconds as opposed to the 60-90 milliseconds of the Phase 5 software.

For all applications that we could now convert 1:1 this improved technique yielded a speed increase on the PowerPC-side that we deemed sufficient. Any application that wants to gain more speed from the PowerPC requires special programming anyways. In this case, the developers should be aware that they have to undergo a tremendous effort for only a small target-market - this will most likely not pay off in the software-market for dual-processor boards. We were and still are convinced that future Amiga models will have ONE CPU, regardless of which manufacturer will be supplying it.

After that we spent time improving our developer system and programming the necessary PowerPC-native ANSI- and math-libraries as well as making sure that everything kept working in a stable and Amiga-compliant way. In the month of April we presented our first demos and the developer-system at a club-meeting in Heilbronn and at the "Magic Days" in Trier where we also held a few seminars that dealt with the problems that arise when programming the PowerUP-boards. At the show in Trier we spoke to Wolf Dietrich and Gerald Carda of Phase 5 and asked them to publicly discuss the choice of the object format and the concept of the PowerPC-interface. This idea was, as you might have guessed, rejected. The reason we were given was simple: "We have decided it that way and this way it will be done. There will be no discussion!"

A short time after the show, a new version of the software-interface (PPC.library) was released by Phase 5 (we hadn't received any new version from the author for more than 3 months). We tested the new library and, as could be expected, our software would not run anymore. The changes made to the PPC.library had been so significant that even what had been a legal approach only a few months back was not usable anymore.

In order to avoid further incompatitibilities with the Phase 5 solution, we compiled a list of requirements that would ensure Amiga-compliant access to the PPC.library in order to define a standardized interface to the PPC.library in cooperation with Phase 5. This list was discussed by our authors and Mr. Carda at Phase 5 (the author of the PPC.library had canceled at short notice), given a quick okay but not incorporated until this day! When presenting our solution and its capabilities at the same occasion, Phase 5 were amazed to see that our author Sam Jordan had accumulated a knowledge about the PPC that exceeded that of the Phase 5 developers and probably still exceeds it today.

Four weeks later, a new version of the PPC.library was released that had a number of features that we had presented earlier in our solution. The suspicion that Phase 5 had "re-engineered" our software was not far-fetched. This version of the PPC.library was yet again incompatible to our solution, a fact that did not surprise us a lot anymore.

As a consequence to the persistent ignorance of Phase 5, we decided to create our own software solution to entirely replace the PPC.library and to do so as soon as possible. This should not, however, mark the end of our willingness for cooperation. On June 5, 1997 the first version of our PowerPC- and Warp.library successfully worked after first removing the PPC.library from the LIBS:-directory!

Up to this date we have still taken care to provide a solution that cooperates with the interface provided by Phase 5 - in the same way that was previously accepted and tolerated by Phase 5. The two further versions of the PPC.library by Phase 5 that reached us until this day again refused to work with our software-interface. Times and times again we had to adapt our software and add workarounds for bugs of the Phase 5 programming.

As a highlight we must mention the change that was made to the library around the end of July. As we all know, Phase 5 had already announced the boards to be shipping in June. That date was getting delayed week by week. At the end of July, Phase 5 provided yet another version of the library - this time it was necessary to completely recompile any software that had already been created in ELF-format for PowerUP. We could not understand this at all, especially since the boards were scheduled to be shipping months earlier. By the way, developments that were based on StormC were not affected by this. Only a very small part of the compatible library had to be re-compiled to get everything up and running on the Phase 5 PowerUP again.

The latest version of the PPC.library was provided to us together with the PowerUP consumer-board. It also included the first documentation for the "revolutionary" messaging system that was at least half complete. Developers that were planning to develop PowerUP-software could therefore only now start the development process. That is one of the reasons why there is no application software for PowerUP yet. Anything that had been developed earlier must now be changed in concept and re-programmed with a lot of effort.

Developers that currently decide to program software for PowerUP using the Phase 5 approach must be aware that their software will most likely NOT run on PowerPC-boards of competing manufacturers and neither will it run on a potentially planned PowerPC-Amiga. The statement by Phase 5 in which they claim WarpUP to be a "Hacker Kernel" shows their fear of any potential competition.

Very similar to what is happening now, Phase 5 denied ProDAD support a year ago. Phase 5 might counter this by saying that ProDAD also received a developer-board and were able to develop. What they won't tell you is that Phase 5 never laid open the hardware specifications - a dire necessity if you want to develop an operating system for the PowerUP-boards.

Solutions and Ways

For you as a user this discussion might be absolutely of no use at all. But if you want to buy a PowerPC-optimized software product and have to pay attention to whether it supports the PowerPC board of company X or Y, you will ask yourself why nobody cared to provide a standard for this right away.

We as a software-company do neither have the time nor the necessary resources in order to provide software concepts for every new Amiga-hardware-platform. The same applies to many other companies, and that is why a hardware-independent interface between the 68K-operating-system and PowerPC-control-software must be defined. This definition must be made in a way that neither puts hard- nor software-companies at a disadvantage and that avoids any market-monopoly to arise. For this reason it is necessary to install an independent consortium that sets the necessary standards.

Our proposition shows a possible way that can be flexibly adapted. As an independent software-developer we are of course willing to adapt our interface for other Amiga-PowerPC-platforms in order to ensure that the software will run. Support for the ELF-object-format is of course possible as well, if an independent consortium can be convinced of its advantage for the future of the Amiga. The arguments currently provided by Phase 5are not likely to convince any developer unless he plans to abandon Amiga-development and wants to orientate himself towards the A\BOX. Talking about industry standards and a list of development systems that could possibly be used on different and more expensive platforms completely misses the point. Phase 5 might be in the situation to be able to afford such development systems, but this will not cause development to become any faster. In our opinion, software development for the Amiga should continue to be made on the Amiga.

It was some time ago, when the UK company Index that already holds a license for building Amiga-Clones and selling the AmigaOS, announced RISC-based accelerator-board. Every software developer who read this announcement has to consider the question whether applications must be adapted once, or once for every board. The software-solution by Phase 5 contains - from the point of an AmigaOS developer - so many significant changes (ELF-format instead of Hunk-Format, dynamic linking instead of shared-libraries) that it is virtually impossible for any other PowerPC-hardware-developer to also provide this interface. And the possibility of licensing the software from Phase 5 is highly questionable when looking at their current behavior and has not yet been announced by them.

Only when a binding standard has been agreed on can software-houses start porting their software, certain in the knowledge that manufacturers of different PowerPC-boards will have to provide compatible solutions. Only then can the user be sure that nobody will try to have his own way.

In shape of the PowerPC-boards by Phase 5, a first step into a wonderful Amiga-future has been made. However, we are of the strong opinion that theirs can not be the only solution and we are hoping for further manufacturers to risk entering the once-again blooming Amiga-market. It is only by means of the necessary competition that innovative development can be ensured.

The accusation of Phase 5 that WarpUP is solely designed to favor StormC as the development system for PowerPC applications is simply false! Every developer of compiler systems has the chance to create a PowerPC-compiler. This compiler can write the Amiga-hunk-format like it always has. It is the programmer of the application (or, in the case of StormC, the runtime-system) who takes care of the specialties of the PowerPC and uses the PowerPC.library of WarpOS to handle these. Since the PowerPC.library is a 100% Amiga-compatible shared-library, it is usable by everybody. It is easily possible to use a different compiler for the 68K-part (e.g. SAS/C for an existing application) and the PPC-part (e.g. StormC-PPC for the ported parts) in one Mixed-Binary. We will be happy to help any company wanting to port their compiler for the PowerPC with the experience we have gained in the past two years.

We are very interested in cooperation with Phase 5 and all other companies that want to make new PowerPC-developments, as well as in cooperation with Amiga International. At the same time we wish for a peaceful co-existence of alternative solutions IF these provide useful extensions and do not exclude a common application interface.