Will OS4 have SMP after all

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

[takemehomegrandma]

You cannot mix everything.

On MorphOS you can!

Old 68k legacy apps (and libraries and other system components) happily mixed with new PPC ones, scheduled by the same scheduler and sharing the same HW and OS resources, in the same environment, in a completely seamless way (of course they aren't really 68k anymore but the binaries has been recompiled into native PPC binaries, but the apps don't even know this themselves, so... ). Please don't belittle this. It's not something trivial, it's not unimportant. The MorphOS environment *is* the Amiga environment, greatly improved, and where the meaning of 68k/PPC has been marginalized to a minimum, this is what makes it possible to say:

MorphOS is Amiga done right!

[Iggy]

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

[OlafS3]

Yes I know :-)

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

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

[OlafS3]

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

to what price?

I personal can only hope MorphOS sticks to PPC (as AmigaOS) so no competition for AROS on X86/X64 for a long time :-)

[wawrzon]

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 :-)

but i wasnt able to find any forbid() in aros v1 source yesterday, can you point me to an occurence, so that i have even the slightest idea about the issue?

[wawrzon]

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)

personally i think it will have to be dealt with at the proper time, that means when it will become an issue. it has been also already talked of. possible solution is of course fork aros for 68k and update it from the main tree only where it is appropriate. something like that happens already, when krzysztof ports features from experimental aros v1 to public v0. v0 will never become v1, but will gain some of its portable features for the time being.

[Blizz1220]

to what price?

I personal can only hope MorphOS sticks to PPC (as AmigaOS) so no competition for AROS on X86/X64 for a long time :-)

You seem to be forgetting that Aros is free so "competition" ROFL

Morphos and Aros camps combined (let's leave millions of AOS 4 users
out of it ) , number in thousands of souls ...
New users are what is needed and if there is no new users coming now
that both Morphos and Aros are mature and everyone can afford them
then what is the whole point in investing even more time and muscle
in it ?

More promotion is what is needed , both Aros and Morphos are way
cool OSes from a general PC/Windows/Linux perspective and are
fun to use ...

[OlafS3]

You seem to be forgetting that Aros is free so "competition" ROFL

Morphos and Aros camps combined (let's leave millions of AOS 4 users
out of it ) , number in thousands of souls ...
New users are what is needed and if there is no new users coming now
that both Morphos and Aros are mature and everyone can afford them
then what is the whole point in investing even more time and muscle
in it ?

More promotion is what is needed , both Aros and Morphos are way
cool OSes from a general PC/Windows/Linux perspective and are
fun to use ...

Yes they are. And I try that already (to a certain degree). The problem is no software no user, no user no software. We must overcome this circle. It is not a technical problem like many user think, like missing MP.

[Iggy]

@Blizz1220

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

[Blizz1220]

Well having some new cheap Amiga hardware that could be called
Amiga and run Morphos/Aros/AOS4 certainly would not hurt general
user numbers ...

The name Amiga lost all of it's value after Gateway but it is slowly
thanks to Internet and die-hard Amiga lunatics starting to get some
value again ... Even a few thousands new users coming to all three
camps combined would bring a welcoming change , only new users
have enough life left in them to promote Amiga further ...

[bloodline]

but i wasnt able to find any forbid() in aros v1 source yesterday, can you point me to an occurence, so that i have even the slightest idea about the issue?

forbid() is part of the exec.library API, and loads of Amiga software uses it as it is a quick and simple way of locking a resource and making sure your operation is atomic... But for a while now, AROS devs have been encouraged to use alternative locking methods that don't freeze the system.

Also there is no issue with AROS 68k or any other AROS port if AROS gets a working SMP implementation, if the system only have one CPU it will work just as AROS/AmigaOS does now... And key to any implementation is that is doesn't break older software anyway (even if that means the older software might be slowing down the newer software, if that is an issue, don't run the older software or rewrite it to take advantage of the newer systems).

[kamelito]

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

Kamelito

[OlafS3]

forbid() is part of the exec.library API, and loads of Amiga software uses it as it is a quick and simple way of locking a resource and making sure your operation is atomic... But for a while now, AROS devs have been encouraged to use alternative locking methods that don't freeze the system.

Also there is no issue with AROS 68k or any other AROS port if AROS gets a working SMP implementation, if the system only have one CPU it will work just as AROS/AmigaOS does now... And key to any implementation is that is doesn't break older software anyway (even if that means the older software might be slowing down the newer software, if that is an issue, don't run the older software or rewrite it to take advantage of the newer systems).

I do not know what is planned. I personal would wish a kind of compatibility mode so it is possible to run it more compatible to old software or with new features when you only use newer software.

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