Bonjour à tous,

Voici un article trouvé sur http://via.i-networx.de:

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

Je ne suis pas en mesure de juger du sérieux et de la faisabilité de tout ce qui est ici raconté, mais c'est certain qu'il faudrait un grand coup de rénovation du system et le développement de la Qbox avec tout ce qu'elle permettrai est une évidence. Pour moi qui suis l'épopée MorphOS depuis son tout début, la Qbox a toujours été un élément d'espoir pour remettre l'AmigaOS au rang des systèmes modernes.

La question qui reste est de savoir si la MorphOS Team a encore le courage, le temps et les moyens de reprendre tout cela de presque zéro.
Pour moi, la Abox était un élément de transition entre l'AmigaOS68k et le vrai MorphOS, hors elle est devenue un but en soit durant toutes ces années.

Pour la petite anecdote, le premier article que j'ai lu sur MorphOS exposait le principe des boxes et il y était évoqué la possibilité que MorphOS puisse accueillir la Abox pour AmigaBox mais aussi une AtariBox ou encore une MacBox et que toutes pourraient cohabiter en même temps. C'était à l'époque une véritable avancé dans le domaine des systèmes capables d'heberger plusieurs environnements très différents comme le permet maintenant les technologies de virtualization.

Comme quoi, on passe notre temps a rater des occasions et a ne pas profiter de ce que nous avons de plus intelligent et en avance sur les autres. Aujourd'hui tous les systèmes modernes sont en mesure de faire cela mais nous, on n'en a jamais profité.

ma plus grosse crainte c'est que la Qbox soit réduite à ça:
http://www.oli-hummel.de/morphos/qbox.jpg
http://tokai.binaryriot.org/private/emphasis.jpg



En même temps, je critique mais suis certain que la MorphOS Team nous prépare quelque chose de bien pour l'avenir ;-)

Il n'y a pas foule qui s'intéresse ou comprennent les entrailles de MorphOS !!!

Je suis surpris du manque de réaction des Morphoésiens français sur cette question de fond !!!

Cela dit, ça peut se comprendre, c'est comme aimer les belles voitures sans chercher à comprendre comment le moteur fonctionne, ce qui compte c'est l'expérience que l'on en fait :-) pour autant, heureusement que des gens cherchent a améliorer toujours ce cœur mystérieux qui fait rouler la machine.

J'ai lu mais je capte rien...C'est comme une sorte de virtualbox, ou parallels, c'est ça ? OU c'est un truc genre "linux hosted", comme sur Aeros ?

@ Demether: je te rassure moi non plus :-D

Un membre de la MorphOS Team pourrait-il nous en dire un peu plus ?

Avant-propos : tout ce qui est écrit ci-dessous vient de ce que j'ai compris par mes diverses lectures/discussions... Donc sûrement approximatif mais cela permet de comprendre le principe "de base". De plus, je ne suis pas membre de la MorphOS Team, donc mes propos n'ont pas de véritables valeurs ^^

Pour essayer de résumer schématiquement, la QBox est une "nouvelle boîte", tout comme l'ABox est une boîte, et elle repose sur Quark, le noyau. La QBox existe déjà puisque c'est elle qui initialise tout et dans celle-ci que tourne l'ABox. L'ABox pourrait être considérée comme un processus de la QBox.
La QBox est bien plus "évoluée" et possède la protection mémoire et le support des multi-processeurs, mémoire virtuelle, etc.

Mais pourquoi l'ABox ne possède donc pas tout ça me direz-vous ? Car l'ABox a un A comme Amiga et cela signifie qu'elle est compatible avec les API Amiga... ce qui fait qu'on ne peut pas implémenter tout ça sans casser la compatibilité...

Il faut voir la QBox comme un socle sur lequel se pose l'ABox, et d'autres boîtes pourraient venir se poser sur cette QBox. On pourrait donc, rebooter l'ABox sans redémarrer la QBox, si vous avez suivi mon idée ^^

Alors, si on veut utiliser les caractéristiques de la QBox, ben faut développer un OS utilisant les caractéristiques de celle-ci mais qui ne sera plus compatible avec les API Amiga. L'avantage de la QBox, c'est qu'elle servira de base pour la migration vers un autre proc', le désavantage, c'est que l'ABox telle qu'on la connait ne pourra pas en tirer parti... mais on pourrait imaginer la QBox tournant en "parallèle" de l'ABox (mais lÃ, je sens que je m'avance trop... pas sûr qu'on puisse partager le truc si "simplement").

En fait, c'est un peu près la même idée que ce qui a été mis en place par Apple pour faire tourner MacOS 9 sur MacOS X, mais eux avaient les moyens...


Et sur les bons conseils d'henes, allez jeter un oeil sur le site MorphOS.de dispo sur Web.archive :
http://web.archive.org/web/20000819060436/http://www.morphos.de/overview.php3 (d'ailleurs, Ã la base, l'ABox ne devait pas être si "développée"...)

--
/me espère n'avoir pas dit trop de conneries et avoir été clair, mais c'est pas gagné ^^

En tout cas c'est plus clair, c'est pas un truc de virtualisation ou autre, je comprends mieux ;-)

Merci BatteMan pour ce résumé.

Ce qui n'a jamais été très évident pour moi, c'est la limite distinguant la Qbox de Quark.

Ce que j'aurais aussi aimé savoir c'est quels éléments dépendent clairement de Quark, de la Qbox et de la Abox.

De toute évidence, la Abox communique avec le matériel comme si elle se comportait seule sur un amiga classic car c'est ainsi que les drivers et devices restent "compatibles" avec les Amigas classics, mais en réalité, quelle est la part de travail fait entre la Abox, la Qbox et Quark? Qui de la Qbox ou de Quark accède pour de vrai au matériel? Est ce partagé? si oui, quels éléments traversent la Qbox pour communiquer avec Quark et quels autres dialoguent directement entrre la Abox et Quark?

Ce serait génial d'avoir un schéma décrivant l'imbrication de tous ces éléments et leur rôle.

Pareil, merci beaucoup Batteman pour ces explications qui nous permettent d'en savoir un peu plus sur notre "bolide" :-D