As many regulars to this web site will know, I am a keen enthusiast of developments in the next generation of Amiga hardware and software. Recently, I have been making some investigations into developing software for a platform which can no longer rely on a specific, ever-present hardware core. In the past, a single Amiga binary could be distributed for all systems, since every Amiga used the same hardware. But now, developers must face the fact that their code could be running on any of several Amiga platforms. In this article, I would like to make some brief comments about the various hardware and OS configurations, current and future, which are around, and how developers can solve the problem of distributing software for multiple systems.
At the time of writing, there is only one official system: a 680X0 based Amiga running one of several versions of the Amiga OS. Some of these Amigas are equipped with a PowerPC processor running in parallel with the 68k CPU. Every Amiga user and developer knows these machines and supports them without problem.
Fine so far, but in the future we will see a shift to an official OS running on a PowerPC or other processor. The use of PowerPC accelerators in the meantime has meant that PPC software can already be developed, starting with hybrid 68k/PPC code before moving over to native PPC code. Apple had emulation of the 68k code running on a PowerPC when it moved to PowerMac architectures, so it is likely that old software will eventually run happily on PPC Amigas under emulation, when a native OS is released. Again, all is fine so far because developers can write 680X0 code for all, and PowerPC specific code for those with PowerAmigas.
Now the problem. A portable, multi-platform Amiga OS clone called AROS is available for many systems right now. It is binary compatible on standard Amigas, but requires software to be recompiled for other systems. There are no intrinsic problems with this because most users of AROS have the skills to recompile software with no problem - plus it is binary compatible on 68k Amigas and probably will be for 68k/PowerPC hybrid systems in the future. However, users require the source for using software on non-68k systems - not something usually shipped with commercial programs such as applications or games.
Now extrapolate that for an official OS (or even pOS) which could be running on anything from a PIOS PowerPC system to a Gateway 2000 Pentium, a DEC Alpha to an Acorn/Oracle NC. How do you support all these systems? How do you support future systems? Let's have a look at the options available...
AROS follows the UNIX idea (which coped with multiple-platform software distribution decades ago) by providing compatibility through recompilation. This is a good system in that it automatically supports, through correct coding and library support, any platform running an Amiga OS. The developer doesn't need to have compilers for individual systems either, so long as care is taken to make the code conform to certain portability guidelines.
However, most computer users do not have the skills to recompile software for their system, nor should they need to in these days of user-friendly computers. Plus, most developers probably don't want their coding tricks and algorithms to be exposed to the world as visible source code. Okay, it worked for the UNIX world, but UNIX wasn't what average users had running on their home machines. It's a great method for distributing portable code, but unduly complex for the average user - most people want things ready to run, right from the box.
So what about precompiled binaries then? We get back the ease of execution, just click and go, but developers need to have compilers for all possible systems. As the range of systems increase, developers start to have problems supporting everyone and so new or minority systems lose out. Plus, how do we distribute them? Lots of separate binaries equals lots of space - but CDs, the new DVDs and other future storage devices offer lots of room to put them, so why worry...
Talking of precompiled binaries, we also have the so-called "Fat Binary" - one executable using several sets of processor code rolled into one bulky binary. While okay for systems such as the 68k/PowerPC hybrids, it really is unnecessary. Who really wants to have a large binary, of which a significant chunk is unused by your specific system? However, the advantage is that only one binary is shipped, all execution is transparently handled by the OS and you can happily swap software between different systems without recompilation (good for multi-platform networks, one binary serves all). Otherwise, it really is just an ugly way of handling multiple binaries, in my opinion, with all the same inherent problems.
Emulation of some binaries (i.e. 68k and PPC ones) on other platforms is a possibility, but emulation is slow and we really get back to the pros and cons of multiple binaries again. Plus, which systems' binaries do we support and which do we emulate?
Of course, there is another system which needs only one binary and which automatically supports all systems (present and future) and offers the advantage of being suitable for emulators on other machines. We simply compile a binary for a Virtual Amiga. As Java programmers will already know, having a binary for a virtual machine allows you to run the same compiled code on any system which emulates it. Of course, what happens is that the binary is interpreted on a given machine, leading to slower execution than native code. Java, for example, runs at about a tenth of the speed of native C code. Yuk!
Or is it? System calls would be implemented using native code, so we wouldn't have any reduction in speed there - most of the Amiga libraries would also come under this category too. Plus, processor power is constantly getting better and most applications software is idle for large periods of time anyway. So, for most software you probably won't notice a difference. It's certainly an elegant system, compact and ideal for computing on multiple platforms, but the disadvantage is the reduction of raw processing performance.
In the end, it all depends on which developers make the most effort, and which systems the Amiga OS becomes available for. However, the situation does need to be addressed as part of the whole move to the next generation of Amigas. Only the AROS team seems to have addressed these concerns (perhaps because of their proximity to the problem), while the rest of the industry concentrates on 68k and PowerPC support exclusively. That's why I decided to highlight the situation so that, hopefully, those who haven't thought about the long term problems will take note.
I would be interested to hear of anything related to this topic. If you are involved in, or know of, any multi-platform Amiga developments or have ideas and opinions on the subject let me know!
Interesting news about Apple - they've bought up Power Computing and decided to stop companies from making clones of the Macintosh. I hope Steve Jobs knows what he's doing, because it seems like suicide to me. Still, with all those PowerPC systems lacking MacOS in the future, what can future PowerPC machines run? Well, Be seem perfectly happy... after all, their OS runs happily on the various PowerMac clone incarnations and many companies will shift over to them rather than ditch the PowerPC market. Free versions of BeOS are being shipped with several PowerMac clones, attached to magazine covers and passed out at various shows... with a huge market to exploit.
But if Amiga International had a PowerPC native version of Amiga OS available, think of the aggressive marketing they could also be doing to get it onto all those PowerPC clones. It's a large market, and with Apple's strange decision Gateway could be dishing out cheap licences of the OS to all those manufacturers... if only they had the OS available. Come on people, get that native OS out NOW! If you need programmers, I'd offer my services and I'm sure others out there would to... this could be the opportunity we need, but we aren't able to take it!