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.

[wawrzon]

It would be nice not to have to resort to UAE.

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.

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.

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.

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

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.

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

[OlafS3]

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.

[pVC]

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.

I for example have still lots of 68k libraries, mui classes, shell commands, devices, datatypes, filesystems, commodities, system enhancement programs etc in use on my MorphOS setups. Many of them aren't available for porting anymore...

And then I want to use same ARexx ports, clipboards, filesystem, network etc with 68k apps. I don't know if there's something done for those in AROS "sandboxes" for example. Of course UAE is fine for games etc, but these kinds of resource sharing things come in my mind for productivity use. Not to talk about GUI part if application has several windows/screens etc? I wouldn't like to use them less integrated to main system...

[OlafS3]

JanusUAE is sharing clipboard but f.e. not AREXX port. You can add AREXX in AROS 68k by simply copy rexxsyslib and rexxmast. I know that there is some sort of AREXX implementation on AROS X86 but I do not think that the ports between both worlds are shared. Filesystem sharing should be possible (have not tested it myself because I mostly use AROS 68k on WinUAE). But even if all is shared there is a loss compared to the solution in MorphOS and AmigaOS. On the other hand the OS is freed to run on modern hardware.

[Blizz1220]

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?

PPC Linux with a butterfly logo

[bloodline]

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.

You are always going to have to have forbid() (and also disable()), and it is probably always going to be a nasty big lock over the whole system because that's part of the AmigaOS API and old Amiga program's expect it... But what you can do is "depreciate" the function, that is to say remove it from the API documentation and give developers other more fine grained locking mechanisms... That way it stays for compatibility, but is only used in some horrible old app that hopefully will be replaced with something nicer :-)

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

[bloodline]

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.

And...?

[takemehomegrandma]

Is it possible to have one version single core, and then slowly migrate the software to multi-core? You could dual boot either version.

Of course you could have 2 separate OS's and dualboot between them (like you always could)...

All of this is bull****. If current amiga ng os systems can't do smp then say goodbye and reboot to ng/2

I think this is the plan for the MorphOS Team. At least they have said they will migrate to another CPU architecture and that they are working to make the OS 64-bit (on a virtual machine for development purposes). Possibly SMP etc as well while they're at it, who knows?

It would be nice not to have to resort to UAE.

When you start incorporating things like SMP you don't have much of a choice, you need a sandbox for the legacy. Problem isn't the new/existing/still maintained applications (they can be adapted), problem is the old Amiga apps whose whole existence and ability to function requires the environment to be and behave in the Amiga way, and that is not compatible with SMP. If you are to move to x86/ARM you will also face little/big endian incompatibility. UAE is a quick and nice option IMHO. Works for OK AROS AFAIK. Indeed it's not the same as what we have today, but in order to move forward (x86, x64/64-bit, memory protection, possibility of going SMP etc) with all the benefits that may bring, I think this is a cheap price to pay.

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.

Funny thing is that if AROS would also go this "NG/2"-route, then a 68k "distro" of this version/branch of AROS would also have to use UAE for legacy Amiga 68k apps, even when running on a real 68k Amiga! (Not that there are a great deal of 68k Amigas with multiple CPU's :lol:, but the "NG/2"-differences in the OS itself would require it)

[Blizz1220]

Why do you need SMP anyway , just to prove you can do it ?

How many Amiga apps or games do actually need all that speed ?

I can see benefit from MPlayer or Web Plugins using the other cores
in an AMP way but what is the benefit to forcing it into any Amiga Os ?

Hardware is fast enough for Amiga needs already , do you really have
to make it less Amiga just so you could gain questionable amount of
speed at the price of all that hard work

[OlafS3]

And...?

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

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

[takemehomegrandma]

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.

The current MorphOS model (and its implementation) is beautiful, simply put. There is no denying in that. It would be sad to lose it in a way, kind of traumatic even, but IMHO taking the OS further by incorporating the features we are discussing here and also migrating to a different ISA wold be totally worth it.

There is no future on PPC, MorphOS has lived its life in this incarnation as long as it could, it has sure made the most out of it and utilized all the best HW, but I think the PPC road for MorphOS has come to its end. An ISA migration requires a change in the MorphOS model, which is sad, but it would allow the OS to evolve further. And when the legacy is cut off anyway, there is nothing (but time, energy and motivation) preventing an exploration of new, "modern" OS features. This could mean many great things!

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