Will OS4 have SMP after all

[Iggy]

UAE on AROS and native AROS apps shared a graphical user interface too... That was kind of the point

Yeah, but you routinely keep ignoring the point that the OS calls don't need to going through interpretation.

What you are talking about is less efficient.

[bloodline]

A clone of Trance with seamless byte-swapping would be nice.  Shame Emumiga never got off the ground.

I know, I really liked the whole Emumiga concept, but it was a complex idea... I had a look at resurrecting it myself, but it was out of my league... Especially with how little time I had.

[bloodline]

Yeah, but you routinely keep ignoring the point that the OS calls don't need to going through interpretation.

What you are talking about is less efficient.

I know it is less efficient, but the idea is that it is only to run a few old apps and you get the bonus of all our old hardware hitting software working too (which you don't get with the AOS4/MOS system).

As a user running AROS on a 8Gig 3Ghz+ multicore computer, you are probably going not going to worry that it's slightly less efficient... But is more compatible

[Iggy]

I know it is less efficient, but the idea is that it is only to run a few old apps and you get the bonus of all our old hardware hitting software working too (which you don't get with the AOS4/MOS system).

As a user running AROS on a 8Gig 3Ghz+ multicore computer, you are probably going not going to worry that it's slightly less efficient... But is more compatible

Well, with AOS4 Classic you do because the hardware is there.

[bloodline]

Well, with AOS4 Classic you do because the hardware is there.

That's a little off topic, AOS4 classic is never going to have SMP

[nicholas]

That's a little off topic, AOS4 classic is never going to have SMP

There's nothing to stop an opensource OS that is yet to be written from running on the BPPC and farming out 68k processes to the onboard 060 though.

[bloodline]

There's nothing to stop an opensource OS that is yet to be written from running on the BPPC and farming out 68k processes to the onboard 060 though.

The the CPUs in question are not identical, then that's not SMP

[nicholas]

The the CPUs in question are not identical, then that's not SMP

True.

[Iggy]

That's a little off topic, AOS4 classic is never going to have SMP

You are nitpicking.
And, no, there will never be new PPC accelerators for classic hardware.
Especially with more than one core.
At some point abandoning legacy hardware makes sense.

So i will agree with you that emulation should prove adequate.
Because you would hope that better native software would be developed and the old software marginalized.

[nicholas]

And, no, there will never be new PPC accelerators for classic hardware.
Especially with more than one core.

Not if we all start praying!

http://ultimateppc.nl/

[OlafS3]

for that project we would really need a wonder :-)

besides it was not able to do SMP. Or was something like PowerUP planned?

[Fats]

AROS encourages the use of semaphores to lock resources.

Currently AROS' Semaphore implementation is using Forbid()...

[LoadWB]

There's nothing to stop an opensource OS that is yet to be written from running on the BPPC and farming out 68k processes to the onboard 060 though.

Nay-sayers.

[Fats]

Does anyone have a guess when it will be finished?

It will never be finished and I think you don't want that MorpOS ever will be declared finished...

[Fats]

What if a modified exec was running on top of a modified Linux kernel that enabled SMP by distributing Amiga processes across various cores?

A kind of Amithlon on steroids?

This does not solve the problem for the programs relying on the fact that no other program will access memory between Forbid()/Permit().

[Fats]

The advantage of the 68k emulation in AOS4 and MOS is that the 68k and PPC apps live in the same environment and can share libraries etc... It is only possible because the 68K and PPC are big endien...

And by using non-native C struct packing on the PPC side.