Will OS4 have SMP after all

[Iggy]

uae is a sandbox, isnt it?

It would be nice not to have to resort to UAE.
The biggest problem you're going to have is the need to halt the other cores  when the one running AOS wants to execute a Forbid().
Its the simplest way to prevent a crash.

MorphOS will face a similar problem, but the developers are seriously considering dropping legacy compatibility.

[Iggy]

why? legacy code needs 68k emu anyway. uae/68k code may be treated as java of amiga world. one could push uea integration forward with some intelligent ideas. for instance perhaps it is possible to fire up only the 68k emulation and very necessary uae features first, on run of the 68k program to spare cpu power, then as soon as (and if at all) the program makes any call to amiga chipset features those could be dynamically thrown on in emulation.


apparently not an issue on aros anymore (waiting for confirmation), but may have to be improved, i still observe issues on 68k now and then, not knowing if they may be related.


at the point all three systems will want to go for those extended features that will likely set them on the same level of backward compatibility aros is now, namely uae. lets face it.

Interesting ideas.
I spoiled by MorphOS' excellent JIT software.
Only 68k code needs translation.
Operating system calls are executed natively (and are faster than running UAE).
If I need chipset emulation, then I go to UAE.
Although, with faster, multi-core processors this overhead would be less objectionable.
Of course, if we jettison backward compatibility, what will we have?

[Iggy]

Why do you not have backward compatibility when using UAE? You only have a problem with f.e. libraries that only exist for 68k and cannot be ported. I do not know how often this is the case and how many software needs this. And of course you have a problem with components written in assembler and thus not be portable. But if MorphOS dev are looking in future they have avoided this.

You can tell you are dealing with an AROS supporter by questions like these.
Because the system call will not be native, they will require interpretation.

[Iggy]

And...?

And...AROS is inherently less compatible (and the least stable of the three NG OS').
Does anyone have a guess when it will be finished?

[Iggy]

+1

I do not really understand either. On X86 you have X86 software, on ARM you have ARM, on PPC PPC, on 68k 68k. You cannot mix everything.

Actually, on our PPCs, 68K code runs fine.
That's the point we've been trying to make (that so many of you aren't getting) old code, libraries, tools - far more seemlessly than with UAE.

At one time, to complete a MorphOS installation you had to install parts of AmigaOS (I believe that's still true if you want ARexx).

[Iggy]

takemehomegrandma is right.
Its one of the things that makes the OS stand out

[Iggy]

Yes I know :-)

but that means that it sticks to PPC forever...

I could think of worse things than a four core P5040, with the Abox running on one core.

[Iggy]

@Blizz1220

I'm a relatively new user to MorphOS.
And I didn't own a Amiga until last year.

[Iggy]

Permit() and Fobid() could still be patched to do whatever they want instead of the real thing.

Kamelito

Don't start making sense, you'll piss someone off.

[Iggy]

A working SMP implementation wouldn't break compatibility

It was always planned for MorphOS (Qbox), so I don't see why it would be a problem either.

[Iggy]

Earlier you complained about AROS using UAE as a virtual machine, because of the fact that it would keep the 68k and native environments separate. But now you talk about the QBox, which would be a separate environment from the ABox (what you currently know as MorphOS)... There would be no mixing of environments if the morphOS guys ever decide to develop the QBox side with a user space...

Actually as they would probably feed a common graphic interface, there is always the possibility of transferring info from one to the other.

Again, the concept doesn't resemble UAE which goes out of its way to emulate the entire machine instead of reimplementing what it can natively

For a intelligent dude, your sure are trying hard to miss the point bloodline.

[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.

[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.

[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.