I was looking through a few threads and it's been mentioned a few times about SMP with MorphOS and why it cant be done with AmigaOS etc... Whether or not that is true, what's the chances of MorphOS supporting MP in another way, perhaps different boxes on different CPUs? (ie: abox on 1, lbox [linux box] on 2...) I'd like an lbox... would be nice to be able to dev work related things in a similar environment to that at work... whiles using the abox as the main OS for fun things - but concurrently... just some thoughts.

> what's the chances of MorphOS supporting MP in another way

No idea about Quark boxes, but some statements from MorphOS Team member Krashan regarding the feasibility of A(S)MP on MorphOS:

https://morph.zone/modules/newbb_plus/viewtopic.php?forum=11&topic_id=6465&start=60
https://morph.zone/modules/newbb_plus/viewtopic.php?forum=11&topic_id=6465&start=64
https://morph.zone/modules/newbb_plus/viewtopic.php?forum=11&topic_id=6465&start=70
https://morph.zone/modules/newbb_plus/viewtopic.php?forum=11&topic_id=6775&start=71

Edit: statement from MorphOS Team member pega-1:

"There are some ideas how to use the second, unused one as some sort of co-processor but this is nothing relevant for an initial (and even followup) release(s). MorphOS will stay a single cpu core OS for now and I don't see that changing for various reasons that have been discussed (to death) in the past already...."
https://morph.zone/modules/newbb_plus/viewtopic.php?forum=11&topic_id=7332&start=18

[ Edited by Andreas_Wolf 17.11.2012 - 17:19 ]

Andreas won't venture an opinion on this, but the references he points out make a very good points.

I've asked similar questions about SMP or ASMP via additional boxes myself in the past.

Indeed, at the surface it seems simple. Just add other boxes like an X86 running virtual OS'.

It really isn't that simple. For both to run alongside each other there has to be something over top of both (a hypervisor or other controlling time slicer and coordinator).

How would you move from one to the other? Could software in one box work with software in another box? What controls/limits access to common peripherals? Are the GUI's to be linked, or does control merely pass from one to the other? There's a lot of other questions. Other posters, add a few as I'm sure I've missed several.

When I researched the MPC8640/41D, I was fascinated that each core could use separate memory and run independently. But what your talking about is more complicated then running each core as if it were a separate system.

Right now, I can run older versions of Window under later versions. But there are some serious limitations (especially in areas where a virtual machine runs code that assumes it has total control of the hardware).

Can it be done? Probably. Do the developers have the time, resources, and motivation to make it happen? I have no idea.

Frankly, I think the idea scares them a little. Not from the technical challenges, mind you. Rather, were they to do this, we'd have moved from a very competent hobbyist oriented OS toward something that could potentially be competitive with commercial OS'.

Without a major backer, I won't bet my farm on this one.


Edit- One last thing, I'd love to know more about Quark. The closest other micro kernel I can think of is Radysis/Microware's 68K and PPC kernels under OS-9.
I'd just like to know how small Quark really is and what services it contains.
[ Edited by Jim on 2010/10/1 7:00 ]

[ Edited by Jim on 2010/10/1 7:06 ]

I think the topic of this discussion, and the discussion itself, are a bit imprecise, as they mix multiprocessing (be it symmetrical or not) and virtualization. Virtualization does not need a multicore processor in fact. And an operating system does not need virtualization for supporting multiple cores.

> I think the topic of this discussion, and the discussion itself, are a bit imprecise,
> as they mix multiprocessing (be it symmetrical or not) and virtualization.
> Virtualization does not need a multicore processor in fact. And an operating
> system does not need virtualization for supporting multiple cores.

Yes, back when the Quark kernel still had its dedicated page on the MorphOS website the box concept and SMP capability (for Quark, not for the ABox) were listed as separate features.
On the other hand, I could imagine that the need for scheduling within Quark would be rendered superfluous if each box runs on its own core instead of all boxes running on one single core.

> I've asked similar questions about SMP or ASMP via additional boxes myself
> in the past. [...] For both to run alongside each other there has to be something
> over top of both (a hypervisor or other controlling time slicer and coordinator).

That hypervisor would be (or would have been) part of Quark I guess. Btw, you wouldn't need time slicing for different Quark boxes to run on one core each, but only for different boxes on one single core.

> I'd love to know more about Quark. The closest other micro kernel I can think
> of is Radysis/Microware's 68K and PPC kernels under OS-9. I'd just like to
> know how small Quark really is and what services it contains.

"Quark microkernel borrows concepts from L4 microkernel family but is not an L4 implementation itself. For example the clan, id concept and recursive address mapping comes from L4."
http://en.wikipedia.org/wiki/Quark_(kernel)

Quote:

Nice reference Andreas. And I get a little more info on the Quark micro kernel.

And of course supporting multiple OS boxes wouldn't require additional cores, but it could be a way to make use of them.

Which brings up another question. Were MorphOS developers to consider using additional cores when supporting one the one OS box, would there be two separate paths to running more than one box?
One for the single core systems and another that would spread the tasks across processor cores.

> Were MorphOS developers to consider using additional cores when
> supporting one the one OS box, would there be two separate paths to
> running more than one box? One for the single core systems and
> another that would spread the tasks across processor cores.

I'd say yes. But with the second path and using the ABox as host box it would be restricted to running the guest box through ASMP (and the guest box wouldn't be a native Quark box obviously).

Quote:

Yes, that would be one approach. I'm still unsure that there aren't several other ways this could be done. I believe I was too harsh on the developers.
The fact that there may be more than one way to skin this cat would be far more intimidating than the possibility of commercial sucess.

Once they adopt a specific approach, they've stuck with whatever positive and negative attributes that approach inherently holds.

> I'm still unsure that there aren't several other ways this could be done.

Yes, to have multiple boxes running on a multicore system there would also be a much more obvious way than running further boxes on further cores from within ABox through ASMP: Running further boxes on further cores in parallel to ABox running on core #1 from within Quark through SMP. I think that's what zhulien had in mind when creating this thread. Example for quad core PowerMac G5: ABox on core #1, MacOSX box on core #2, Linux box in SMP mode on cores #3 and #4. These three systems/boxes would all run in parallel, with Quark running beneath as a hypervisor.
That's how I imagine it would be best done on boards with CPU(s) which lack a built-in hardware level hypervisor (like PPC970). On boards with CPU(s) that include a hardware level hypervisor (like QorIQ) you wouldn't need Quark or any other software for hypervising. Example for a board with a quad core QorIQ: Quark+ABox on core #1, Integrity on core #2, Linux in SMP mode on cores #3 and #4.

All you need is something like AROS hosted under Linux which runs in a single Linux process. You could launch it a hundred times. You would launch a new copy for all big tasks/apps. They all basically get their whole old-style OS on their own where they can mess around as much as they want without killing the others. Compositing the GUIs together is not a big problem. Memory waste is irrelevant. Especially on 64 bit machines where you could also mix 32 bit and 64 bit apps.

Quote:

That makes QorIQ look even more attractive. If we had a QorIQ processor (hopefully with AltiVec) based motherboard, we could support (via ASMP) multiple OS boxes on multiple cores and maintain backward compatibility. Multiprocessor support is promised for the X1000, but not implemented yet.

And yes Georg, I'm not surprised you could do this already under AROS.
AROS has to be the only other Amiga related OS I have respect for or interest in.

Did anyone notice the web interview with Natami team member, musician Guillaume Michalakakos?

http://obligement.free.fr/articles_traduction/itwmichalakakos_en.php

He mentioned the unnecessary friction that is present between Amiga descended OS camps (And I agree that we all should be more considerate).
However, one comment was really interesting. He mentioned using MorphOS (which he found interesting) and AmigaOS4 (which he thought was refined enough). So, of the major Amiga related OS', the only really negative comment was on the state of AmigaOS (not the state of AROS - which seems to advance everyday).

> If we had a QorIQ processor (hopefully with AltiVec) based motherboard,
> we could support (via ASMP) multiple OS boxes on multiple cores and
> maintain backward compatibility.

I'm not sure I understand that. Could you elaborate in more detail on how that would work and why that would benefit from or even require a hardware level hypervisor like present in QorIQ?

> Multiprocessor support is promised for the X1000,
> but not implemented yet.

Yes, that's kind of what Trevor Dickinson said, but maybe not what he meant to say. His statement is still a mystery to me and AFAIK he never clarified it.

AltiVec is no real benefit to a hypervisor, Andreas. AltiVec has just been on my mind since you mentioned Freescales renewed support for it.
I'm really happy about that since Freescale seems to be the company that's leading PPC development. Their no longer going to sacrifice backward compatibility (not to mention the obviuos performance benefits).

Trevor Dickinson has repeatedly stated that they know how to support multicore processors, but are not implementing it yet. Then he made that cryptic statement you quoted about not supporting multicore processors with the current motherboard. I still don't get that one. Sell a dual core motherboard and then never support using both cores? Weird.

> AltiVec is no real benefit to a hypervisor

I know that, of course. I asked about your idea of using QorIQ (be it with or without AltiVec, doesn't matter in that context) and its hardware level hypervisor. Nothing about AltiVec there. I wonder how you concluded my question was about AltiVec.
So I ask once more: Could you elaborate in more detail on how your idea would work and why that would benefit from or even require a hardware level hypervisor like present in QorIQ?

> Freescale seems to be the company that's leading PPC development.

In respect to processors suited for desktop computing, yes.

> Trevor Dickinson has repeatedly stated that they know how to support
> multicore processors, but are not implementing it yet.

Really? I didn't come across any such statement except for the one we discussed early September. Do you have links?

I'm confused by the question. You yourself pointed out the advantage of having a hypervisor equipped processor in enabling ASMP without relying too heavily on the kernel. I thought you summed up the practical approaches to ASMP (w/ MorphOS) under various potential hardware bases far better than I could.

And I wish I studiously noted all the information on the web I find for later reference like you do. It would help my recall and serve as a useful reference. But I can't figure out how to note it or where to keep all the references. You can't rely on bookmarks for that many references and its hard to believe you remember them all.

One of these days you're going to have to tell me how you do it. You're a fount of useful information old and current and I don't know how you keep it all in mind. Let alone index and reference it.

> I'm confused by the question.

Then you know how I feel reading your replies ;-)

> You yourself pointed out the advantage of having a hypervisor equipped
> processor in enabling ASMP without relying too heavily on the kernel.

It seems my English skills are lacking because that's really not what I meant to say. Another try:
When running a non-SMP capable OS like MorphOS's ABox on one core of a multicore processor then you don't need any kind of hypervisor (be it software or hardware based) to run other boxes on the other cores through ASMP from within that OS. A hypothetical hypervisor beneath that non-SMP capable OS wouldn't even know that these other boxes exist because they're not native to that hypervisor. It would notice the other cores being used though but couldn't tell them running OS boxes from them running any other kinds of ASMP tasks (for instance video co-processing).
A hardware level hypervisor on the other hand would be useful to run several operating systems in parallel on several cores through SMP, without the need for a software based hypervisor. A non-SMP capable OS, running through the hypervisor on one core, could still leverage other cores through ASMP (while at the same time an SMP capable OS could use multiple cores in a symmetric way of course), but such feasibility wouldn't make sense for running OS boxes as they are better to run natively to the hypervisor, i.e. from within the hypervisor beneath.
I hope I could clear up that misunderstanding.

> I thought you summed up the practical approaches to ASMP (w/ MorphOS) under
> various potential hardware bases

No, I summed up various approaches to leverage multiple processor cores for running several operating systems (or boxes thereof) in parallel. This includes ASMP based approaches (without the need for a hypervisor) as well as SMP based ones (with or without hypervisor).

> you're going to have to tell me how you do it.

https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=6313&forum=11&start=10

And I still believe that, apart from the one cryptic statement we discussed in September, Trevor Dickinson never said anything about multicore support for Nemo/X1000 to the effect of "not implementing it yet" :-)

No as far as Mr. Dickinson goes, most of my impression of the man's endeavors came from sources other than our discussion. I think we've focused more on the hardware than the backer.

Your not at fault for any miss communication. Its totally my fault for not completely following your very concise description of potential approaches. Reading this response has made me realize how thoroughly you analyzed a matter that I didn't want to think out completely.

What scares me is how you differ to people who may not as knowledgeable as yourself (people like Matt at Genesi). You know, most people (actually almost all) that post on Amiga sites would never have been able to state that as clearly.

> as far as Mr. Dickinson goes, most of my impression of the man's
> endeavors came from sources other than our discussion.

Same with me. And still that doesn't change that I haven't read him say the things you remember him saying and that I'd be thankful for a pointer :-)

> you differ to people who may not as knowledgeable as yourself
> (people like Matt at Genesi).

I wouldn't say I'm more knowledgeable than him (or other specific people you might have in mind). I just differ from them in that being a mere user I don't have any commercial interest in the Amiga or MorphOS platform and thus can feel free to be committed to the pure facts, while some others are working on a commercial project or even for a company and thus tend to bias their statements to correspond to the interests of their project/company.

> most people (actually almost all) that post on Amiga sites would never
> have been able to state that as clearly.

I think you may be belittling the knowledge of some of them ;-)