Quote:

Yes.
Example drawing: http://eecatalog.com/images/multicore/2009/pg_14.jpg
(old source)

(something more uptodate (pdf from freescale))

[ Edited by KimmoK 06.06.2014 - 11:55 ]

Quote:

Yes, many of the newer PPCs can enable hypervisor support.
Even the G5 should have had it (I understand it is disabled).
So, with a few minor modifications our current OS could run concurrently with a more modern 64 bit version.

To sum it up: technical possibility is one thing. Feasibility, needed worktime and their relation to achieved outcome is another.

@Krashan

Of course. We just hope it can be done, someday, somehow. I'm prepare to donate to a bounty for that. We got G5 support that way, so I guess it's a way

Quote:

If the MorphOS Dev. Team members ever thought it was a worthwhile effort, I would also support a bounty. From what I have read in this thread though, it does not appear to be worth the effort, because the benefit would be too small and the effort to create it is too great. One or both of those things would need to change, to make any kind of multiprocessing project & bounty worthwhile.

I wonder if the effort to do AMP on AmigaOS4.x will turn out the same as their laptop/netbook, and we will see an announcement 6 months or a year from now telling us that, after further review and working on the project, it has been cancelled, for what ever reason.

I don't wish for anyone to fail at their efforts, but always want real information and updates on progress.

@WB_Coder

Multicore, better MP and all that kind of stuff only make sense if you have to break compatibility no matter what you do. My "wish" was rather directed to a 64 bit version. Memory handling in MorphOS works quite well (you can never do anything about bad code: it crashes on MOS as well as Windows) and the system doesn't feel sluggish even on 10 year old HW.

I'm a little wishy-washy when it comes to MorphOS and these kinds of requests. On the one hand I would really welcome new, modern hardware (even expensive hardware if it was worth it) and a 64 bit version. On the other hand, as soon as I remind myself that just changing HW doesn't mean that users nor new (or even old) software will automatically appear, I become less enthusiastic. My bet is that a lot of the people on various Amiga forums who claims they would buy an Amiga system if it was cheap wouldn't really. They would start complaining that there are no software etc.

That's why I think the best approach would be to make the 64 bit MorphOS on a G5 so you could have a dual boot. It would give programmers a way to start porting to that system. But it also only make sense if you stick with PPC (let's see how Open POWER works out).

Damn if you do, damn if you don't ...

Silly SMP implementation in AROS is open and you can follow its progress with little effort. You knew it already but I wanted to remind about it because it attempts to preserve maximum source code compatibility.

@itix

Yes, I heard that it was very slow. Too slow to be at all usable even.

Quote:
Not sure, but I don't think it's any less unusable than "no SMP" version. Just not offering enough benefits to bother writing something like it for MorphOS.

Quote:

It is less usable than non-SMP version. AROS developers are trying to make it usable but as now it runs slower and is unstable.

[ Edited by itix 14.06.2014 - 12:22 ]

>> I heard that it was [...] Too slow to be at all usable even.

> I don't think it's any less unusable than "no SMP" version.

Sounds like you're in complete agreement ;-)

Quote:
It's imposible to say on that small quote alone. It can also mean it's "actually making things even slower than non-multicore version", which I doubt...

>>>> I heard that it was [...] Too slow to be at all usable even.

>>> I don't think it's any less unusable than "no SMP" version.

>> Sounds like you're in complete agreement ;-)

> It's imposible to say on that small quote alone.

Actually, my comment was making fun of entanglement in a chain of negations, so that what's written comes out as the opposite of what's meant :-)

https://facebook.com/414578091930728/photos/a.583390791716123.1073741829.414578091930728/674728855915649/?type=1&theater

[ Edited by Intuition 16.06.2014 - 07:59 ]

Quote:

That's one way to do it. (even if not the most "Amigan" way, as it uses linux underneath the hood)

I wonder how the load is shared for both cores.
If it's GL Gears of AROS, it should load only one core, right?
(but perhaps there's SW rendered (on Linux) underneath...)
UPDATE: Damocles gave some info, GL Gears was compiled for ARIX.


(some other ARIX info etc. at eab)

[ Edited by KimmoK 16.06.2014 - 14:31 ]

Amiga isn't SMP compatible, and "Silly SMP" isn't Amiga compatible, it's as simple as that. Sure, if you have to *recompile* all the apps for your OS (or run them in UAE - which again is an Amiga environment, hence it's not SMP compatible) like on most AROS systems, not to mention ARIX, *then* it's a different matter! But this is very different from the environment that MorphOS (or OS4) offers today. And if the Amiga legacy/binary compatibility is to be dropped (in MorphOS) anyway in favor of new features that can't fit into Amiga, then why not implement these things in a *clean* and *proper* way, built from ground up, instead of a "hackish" way that is just, well... Silly? I respect the effort from a "just for fun, lets get our hands dirty and explore how far we can take this" point of view (nothing wrong with that, especially not in an AROS context), but from a design point of view for real, end-user systems, it's a different matter. I think the best thing with "Silly SMP" is its name!



[ Edited by takemehomegrandma 16.06.2014 - 12:16 ]

Quote:

While I always appreciate your input, I don't think we all were talking about "Silly SMP".
Just the few that have mentioned AROS.
We were talking about running our current OS concurrently with an SMP enabled version.
The latter would, by necessity, be incapable of running Amiga applications outside of UAE.
MorphOS would run on one core, leaving the rest for the SMP OS.

For running legacy Amiga and MorphOS applications, this would be ideal.

And the SMP capable OS would be a great stepping stone to a 64 bit OS on a new ISA.

Quote:

Quoted for future reference. ;)

Quote:
Sounds line an excellent way forward to me. It all depends on the MorphOS team though.

That sounds like a great idea. Since MorphOS has A Box, and Q Box, there could be a third Box that utilizes the multi core support. The third Box can run the legacy programmes (perhaps even if MorphOS became 64 bit) inside the second core.

Or whatever it was that you said. This sounds like an important feature but obviously I am not a coder. The MorphOS Developers are coders and their view is best.

If the above is not possible, then:

There needs to be a concrete explanation to provide for the potential newcomers of MorphOS explaining why MorphOS does not need the Multi Core support.

And if any single core hardware exists and in production, port to it. Perhaps if it is single core hardware, it might cost less ... and low cost hardware is an advantage.

Well, we all know the developers have committed to an eventual ISA change.
But can't that be developed gradually as an evolution of our current environment?

Because even once an ISA change occurs, PPC MorphOS isn't going away any time soon.
Were development to stop at V 3.6, I'd still be able to get many more years of useful service out of our current hardware base.

> MorphOS has [...] Q Box

Does it?

> there could be a third Box that utilizes the multi core support.

That's what the second box aka QBox was supposed to be about.

> The third Box can run the legacy programmes [...] inside the second core.

Wouldn't the ABox be there for running legacy programs?

I did not know about SMP or ASMP was proposed with Q Box.

>>Wouldn't the ABox be there for running legacy programs?

Can the A Box be placed inside the second core? Some similar suggestion from whatever takemehomegrandma and Jim were talking about.

> I did not know about SMP or ASMP was proposed with Q Box.

SMP (as well as memory protection, resource tracking etc.) was the whole point of the QBox idea:

"The goal is to [...] work on a new OS layer using Quark functionality called Q-Box. [...] Because we believe that the original OS design has strong limits for newer technology through its design structure, we also plan a completly fresh and clean OS layer on top of the Quark kernel (called Q-Box now). The A-Box API [...] has serious limitations because it doesn't hide OS structures and has no concept of memory ownership. [...] As a consequence, we will not replicate the A-Box API in the Q-Box but we will try to do a new API without any compromises to the past but based on past experience."
http://web.archive.org/web/20020626181353/http://www.morphos.net/overview.php3

Regarding the "Quark functionality" to be used by the QBox, see there:

http://web.archive.org/web/20020626180435/http://www.morphos.net/kernelinfo.php3

> Can the A Box be placed inside the second core?

Yes, the Quark kernel running underneath both the ABox and any other potential box running in parallel with the ABox would be able to put the ABox on any core, and even switch between cores at runtime. That's the very nature of SMP after all.

Has there been any new statements about the "Q-Box" being a future project of the MorphOS Dev. Team?

I thought that the last word from the Dev. Team (and this was a fairly long time ago) was that the "Q-Box" was dead and had been abandoned, and that only the current "A-Box" would be worked on for the foreseeable future.

This is why I ask if any of the MorphOS Dev. Team members have made an announcement, or even hinted at new work beginning on the "Q-Box".

I also thought that one or more of the Dev. Team members have stated that NO work has been done on any architecture change, and that "IF" any change to a different architecture would be attempted, it would be a long time (years) before it could be completed.

Are my impressions correct, or are there new statements or hints from any Dev. Team members that suggest a different impression of what is happening, or what might happen (or be started) within the next year?