www.via-altera.de
English Version QBox - a possible future option for MorphOS on the x86?
Circumventing the endianness issues of MorphOS
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:
ad 1:
ad 2:
ad 3:
ad 4:
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 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.
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.
--
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.
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.
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).
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.
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).
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.
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.