MorphOS on x86

QBox - a possible future option for MorphOS on the x86?

Circumventing the endianness issues of MorphOS

When MorphOS was introduced a good ten years ago, it was designed to use a box system. What we see and experience today as MorphOS is only one box of MorpOS - the ABox. De facto this is currently the only box of MorphOS and hence the following rule of thumb is valid for now: MorphOS = ABox.

But under the hood there is a little more. At least there is the microkernel "Quark" that sets up the machine, starts a few services and then launches a single user task - the ABox. Initially the idea was that MorphOS should get another box, the QBox. But that box was never specified in detail. And while the QBox didn't materialize, it was probably thought to be very similar to the ABox, but updated with a few modern features.

If we now look to the current state of MorphOS we see a few things:

  • 1st: We all know that the current situation of ppc for desktop machines is a bit difficult to say the least. And the desktop cpu marked is dominated by x86 processors.
  • 2nd: MorphOS (i.e. the ABox) is pretty stable and advanced now, but has its inherent limitations like no resource tracking, no symmetrical multiprocessing (SMP) and no up to date/new hardware
  • 3rd: And we further know that the main obstacle in migrating to x86 is the wrong endianess.
  • 4th: We know that the QBox in the form once roughly anounced (or thought of) is rather dead, but the focus is the brilliant ABox. But still Quark is sitting below.
  • ad 1:
    Since Apple switched from PowerPC to x86, the market for PowerPC desktop machines is de facto dead. PowerPC producers like IBM and Freescale put their focus for PowerPC elsewhere (SoCs, consoles, supercomputers). A few PowerPC machines pop up from time to time, but usually they are expensive and underpowered and produced in homeopathic quantities.
    The desktop (+ notebook, + netbook) computer market is very dominated by x86. Recently ARM processors are much in discussion to join that market, but yet x86 is by far the dominant architecture.
    MorphOS runs on PowerPC only. Hardware supply is warranted through the 2nd hand market of Apple PowerPC computers. For the current situation, this is okay - the hardware is cheap, proven and powerful enough for many tasks. But it is also clear that this hardware doesn't get younger and may break or put to the bin instead of to ebay... While of course it can be that the PowerPC may return to the desktop market, one can hardly rely on this option. Hence, on the long run there must be something else to warrant a future for MorphOS.

    ad 2:
    MorphOS is really nice and stable now. On a well cared setup there are only seldomly crashes. If a program fails most of the time the system doesn't lock up completely. A failing program can most of the times be removed, but not all resources can be freed again. Also the system is pretty safe, but this is rather a safety by obscurity than a safety by design. And while most target hardware is single cored anyway, there is no way to make use of additional cpu cores yet.
    The limitations which are inherent to MorphOS current design are: no SMP, not a full resource tracking, no user management, the netto address space is limited to 31 bit and there is no memory protection.

    ad 3:
    One design goal of MorphOS is to warrant a high backward compability to old Amiga programs that run on a 68k processor. This is achieved by a build in 68k emulation, but also by providing an according compatible environment. One key issue in this regard is the byte ordering. The 68k processor used by the original Commodore Amiga used the big endian byte ordering. And because the operating system shares structures with the applications, the OS and the applications must use the same data format. In the case of MorphOS that is big endian. The PowerPC provides big endian byte ordering, x86 does not, for ARM the story is not that easy (see below).

    ad 4:
    Development of the QBox never took off, instead the ABox was improved and advanced and still holds the drivers and most of that hardware hitting stuff. But the foundation for a box system is there.

    Using the box system for an ISA switch

    Taken all this together, it may be wise to think about an ISA switch to x86 (or maybe ARM, see below). The x86 has one big obstacle though: it has the little endian byte ordering, unfortunately that is the "wrong" one. The question is how to cope with this issue? There is of course the option to run everything with flipped code, but this would lead to some unwanted overhead which would also result in a speed penalty (everything must be flipped by the cpu at run time). But an approach like that seems rather odd for a fast and lightweight OS like MorphOS.

    The proposal made here: A relaunch of the QBox as a kind of ABox x86. MorphOS for x86 processors should consist of two boxes: One little endian box for full speed x86 apps (QBox). And another box (ABox) either running in full ppc emulation or (even better) maybe "just" operated in a completely flipped x86 code environment. That box would provide compability to today (ppc) and yesterday (68k). All the IPC stuff and so on would work like on PowerPC and 68k processors within that box. Due to flipping all data (or emulating PPC or 68k) structures there would be some spedd penalty though. The little endian box (QBox) would be for all new compiles and developments. To reduce developement time and to keep MorphOS as much as it is, the QBox should operate maximally as we know it from the current ABox. But while that box wouldn't be binary compatible to the current ABox anyway, the unique chance should not be missed to implement some critical yet not implementable features like full resource tracking, SMP or useage of a bigger addressspace (more than 1.5 GB RAM). Kind of really modernized ABox. Addition of full memory protection is of course debateable, too. It surely offers some benefit for improved security, but comes at a cost (and personally I rather tend to say the cost doesn't cover the benefit, a good resource tracking is enough and MorphOS doesn't need to become the übersafe OS which qualifies for operation of a nuclear power plant).

    The big endian programs reside in the big endian box (ABox) and cannot access resources outside of this box. For the little endian box this is not a must be, but probably much easier to keep it rather capsulated, too. Nevertheeless a shared clipboard between both boxes and the ability to launch Abox programs from from the QBox should be warranted to avoid two instances of Ambient. And while old applications will never be able to communicate with the QBox, the ABox itself may get some new functions to communicate with the QBox.

    Of course Quark and the QBox would need a lot of virtualization functions and the ABox would require drivers for the virtual devices, but since the ABox and QBox should be very similar, a lot of already existing code should be reusable. It may be a good starting point that current MorphOS supports a virtual gfx driver already.

    Migration to x86

    To keep the development time and resources as minimized as possible it could be a viable option not to include a ppc emulation for the LE ABox (at least initially). On first sight it may seem paradox to rate a PowerPC emulation optional for MorphOS. But it is not - with one prerequisite: the BE ABox must warrant that it can execute x86 flip code. Since most ppc MorphOS programs are not abandoned yet, the authors could compile new x86 versions easily. And while this often sounds like much work it could be done with least effort using the ABox API and generating a BE x86 ABox program. Of course with some extra work the programs could get ported to the QBox API and compiled as x86 LE binary.
    A 68K JIT would be of big advantage though, since many Amiga 68k applications are long time abandoned and there is little chance to get a recompiled x86 version.

    I think with this concept a migration path to x86 without the necessity of a general speed penalty or loss of backward compability can be provided. Plus, I guess a migration to x86 is rather inevitable on the long run. But of course this is much of work (a helluvalot!!) and probably not realistic given the available development resources. Another obstacle is the short time of products staying on the market, it will be rather unlikely to support all hardware on the market, a focus to a certain line of hardware will be required. Apple hardware would probably be a good choice: they have good quality and support, the configurations are usually not much modified by the users and the particular models don't change their specs every two weeks.
    It is also worth to note again, that generally the PowerPC is far from dead - it may have a comeback for desktop computing, but it also may not. And for that case it would be good to have an optional plan.

    A note about ARM processors: The default mode for ARM processors is little endian, but some ARM lines offer big endian modes, too. It is still unclear (at least to me) whether these big endian modes are true big endian modes or just for data compability. For MorphOS to keep backward compability a true bigendian mode is required. A critical test is to look what happens when you set a pointer from a 68k or PowerPC application to address 0x00000004 (the only fix address on MorphOS/Amiga) - does it return exec base or just some random value? If it returns a pointer to exec base, then everything should be fine and there would be no more endian issues. But if this test fails, then there is not much benefit over the little endian mode. Yet I haven't heard a definitive and trustworthy answer regarding this ARM endianness test.

    latest change: 22-09-2011

    © 1999-2013
    Alle Warenzeichen sind Eigentum ihrer jeweiligen Rechteinhaber. Alle Angaben unter Vorbehalt.
    Impressum: Webmaster und verantwortlich für alle Inhalte auf dieser Seite: Ulrich Beckers, Angenetestr. 44, D-33332 Gütersloh
    mailkontakt: u l r i c h . b e c k e r s |at| w e b . d e