@NutsAboutAmiga

When the AROS devs proof that it can be done (and how) perhaps MOS team and Hyperion might be inspired to do it too. At least nobody can claim then that it is not possible. If it is possible in a "68k compatible" way is of course another question. But there must be a kind of break somewhen.

@OlafS25

According to news on Hyperion web page it was forked of into diffrent kernel branches many months ago, they are expermenting, know nothing more as I'm no beta tester.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

Bad excuse for way it can't be done on MorphOS or AmigaOS4, stop it, nothing stops peaple from recompile there programs to optimize for SMP.

Yes, introduce new APIs and recompile existing code base to use new API. Isnt this what I meant?

Quote:

AmigaOS4 and MorphOS are not excatly 100% compatilble whit classic Amiga anyway, way worry so motch about breaking a few rotten apples.

You dont know where those "rotten apples" are until you try and also newer software written for PPC is very likely "rotten".

And another problem is that, as it seems currently, you have to redesign messaging API to get any decent performance out.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

it means changing the implementation or the API itself?

@OlafS25

The API. But I am only speculating because we dont know what is the final performance hit caused by multicore system.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

Since no-copy message passing is a fundamental and heavy used AmigaOS mechanism (for IO as well as the input.device stuff), and any SMP implementation is going to have to involving locking all CPUs while messages are passed about.... I can't see a "win" here?

Pure CPU bound processes *might* benefit, but those are few and far between on a typical Amiga desktop.

Cool idea, and not so impossible to glue on as, say, memory protection, but close to it...?

AROS has the best chance for this "new" stuff though, since they wont have to worry about binary computability, only (perhaps) source computability. And even that can be ignored if they wish.

_________________
Blog

@Aslak3

I am no specialist for OS development but changing the API of the messaging system would certainly strongly affect the 68k compatibility. But as you said with AROS using 68k only in UAE and most applications available in source it is possible. Would be a big problem for both AmigaOS and MorphOS on PPC (as long as they not change the platform, then applications need to be recompiled anyway).

there is already 64bit versions of AROS, if the dev manage to add SMP and finally reach ABI1 then it could become a real modern platform (only MP still missing but I do not know if it can be added at all).

Last edited by OlafS25 on 23-Aug-2013 at 12:55 PM.

@OlafS25

http://en.wikipedia.org/wiki/TRIPOS

Quote:

Influences on the Amiga computer... ... Features The most important TRIPOS concepts have been the non-memory-management approach (meaning no checks are performed to stop programs from using unallocated memory) and message passing by means of passing pointers instead of copying message contents. Those two concepts together allowed for sending and receiving over 1250 packets per second on a 10 MHz Motorola 68010 CPU.

i remember that there is some opposition to giving up the genuine amiga messaging method by passing pointers among aros developers. at least staf was blatantly against it. i dont think jason or whoever else thinks about something like that at the moment.

edit: sorry, wrong quote..

Last edited by wawa on 23-Aug-2013 at 01:06 PM.

@wawa

changing the API would not necessarily mean changing the whole concept. But we will see what results the "real-world" tests bring

@OlafS25

i trust all that it will be a matter of educated discussions. as aros already runs on off the shelf hardware it needs to keep and develop individual concepts that distinguish it from other systems. just copying linux solutions till the point that the system becomes another version of linux is out of the question im sure.

Last edited by wawa on 23-Aug-2013 at 01:20 PM.

"AROS (in my humble option) is here for the betterment of all AmigaOS-alike operating systems. "

Good initiative.

I hope we see more openness in the future (amongs all Amigalike OS developers). Three OS team together solve problems faster than just one very small one.

Last edited by KimmoK on 23-Aug-2013 at 04:52 PM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@Aslak3

Quote:

Aslak3 wrote: @itix Since no-copy message passing is a fundamental and heavy used AmigaOS mechanism (for IO as well as the input.device stuff), and any SMP implementation is going to have to involving locking all CPUs while messages are passed about.... I can't see a "win" here?

Is this really true? AFAIK the message system isn't exposed to that degree that allowing parallel message passing isn't allowed. Not an AmigaOS expert so I may be completely wrong...

Quote:

Pure CPU bound processes *might* benefit, but those are few and far between on a typical Amiga desktop. Cool idea, and not so impossible to glue on as, say, memory protection, but close to it...? AROS has the best chance for this "new" stuff though, since they wont have to worry about binary computability, only (perhaps) source computability. And even that can be ignored if they wish.

@megol

That was the crux of the discussions I read over on amiga.org. Any other process, on any CPU, could be looking in the same message port. The only safe thing to do is halt all processes. AFAICT.

Of course the API could be significantly changed so only selected processes who were interested in that message port could be subject to the locking, but that is a big API change.

Just guessing here as well.

The alternative idea would be to switch to copying the messages about the place. In this day and age, the efficiency gain of zero-copy is less important, but from a purist, Amiga way of doing things, it is hideously inefficient. This message pointer passing goes to the core of what AmigaOS is.

_________________
Blog

Maybe this is a stupid idea but if it is to difficult to
split up the code (yes, i am not a dev) why not use
the different cores as different chips like in the
original Amiga's. A core for the processor, another
one for sound, graphics, network, decoding, etc..

_________________
A1G3-SE + OS4.1 u1 iso (x2)

@Aslak3

Quote:

Since no-copy message passing is a fundamental and heavy used AmigaOS mechanism (for IO as well as the input.device stuff), and any SMP implementation is going to have to involving locking all CPUs while messages are passed about.... I can't see a "win" here?

Operations that manipulate the queue of messages at a port would need to be protected by a mutex (or you'd have to Forbid() ), but AmigaOS have had to protect most operations like that since the launch because of multitasking anyway, and it's only operations that add/remove messages or otherwise manipulate the list pointers themselves, or nodes that are actually in the list, that'd need to be protected.

There's unlikely to be much AmigaOS code where message passing is the performance chokepoint. E.g. you mention input.device etc., and when I overhauled the console.device and console-handler on AROS a couple of years ago, the message passing made up perhaps a few percent of the time spent, and almost all the rest of the time was spent on text rendering.

An AmigaOS app where message passing is a bottleneck on modern hardware would hardly even crawl on a classic Amiga.

There's likely quite a lot of code that Forbid() that ought to use finer grained mechanism (and for many things there *are* no finer grained mechanisms), and that is likely going to be more annoying to deal with.

There are cache coherence issues to deal with, and they may indeed cause challenges, though.

_________________
Wiki for new/returning Amiga users - Projects: ACE basic compiler / FrexxEd / Git

@Aslak3

Quote:

Aslak3 wrote: @megol That was the crux of the discussions I read over on amiga.org. Any other process, on any CPU, could be looking in the same message port. The only safe thing to do is halt all processes. AFAICT.

The important point is if that is exposed. If the current Exec code uses Forbid to serialize accesses to messageports but does so internally that code can be replaced by some other kind of mutex design without causing compatibility problems. Code that assumes that Forbid is used could cause problems but IMHO there is no valid reason why anyone should assume that.

Quote:

Of course the API could be significantly changed so only selected processes who were interested in that message port could be subject to the locking, but that is a big API change.

Don't know if it is. Someone with deep knowledge of the Exec design have to comment on that.

Quote:

Just guessing here as well. The alternative idea would be to switch to copying the messages about the place. In this day and age, the efficiency gain of zero-copy is less important, but from a purist, Amiga way of doing things, it is hideously inefficient. This message pointer passing goes to the core of what AmigaOS is.

´

Well doing it like that isn't backwards compatible. The problem is that AOS exposes all memory and uses untyped messages that can potentially contain pointers. For a new API it may be the best solution (while not the best performing it's easy to reason about).

@megol

Quote:

The important point is if that is exposed. If the current Exec code uses Forbid to serialize accesses to messageports but does so internally that code can be replaced by some other kind of mutex design without causing compatibility problems. Code that assumes that Forbid is used could cause problems but IMHO there is no valid reason why anyone should assume that.

Amiga Exec ROM Kernel Manual says that:

a) PutMsg() or ReplyMsg() can be called from interrupts
b) PutMsg() or ReplyMsg() will not break Forbid

And there are more. And of course OS internals are depending on those.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

Why bother implementing this sort of thing when the OS3.9 API still isn't implemented, 13 years later?

Maybe SMP is more fun for the devs to work on? Obviously they don't care about being useful for the users, or actually implementing the proper AmigaOS API.

Quote:

Dirk-B wrote: Maybe this is a stupid idea but if it is to difficult to split up the code (yes, i am not a dev) why not use the different cores as different chips like in the original Amiga's. A core for the processor, another one for sound, graphics, network, decoding, etc..

It's not a stupid idea or even a new idea. It's called Asymmetric multiprocessing (AMP).

http://en.wikipedia.org/wiki/Asymmetric_multiprocessing

For example, one core could be designated for use by the OS and another as a DSP for audio. It's simpler in a lot of ways and would probably be easier for AROS/AmigaOS to adapt to. Most modern operating systems use SMP which I expect is considerably more efficient. Modern processors can handle a much wider range of tasks than they used to be able to though. This reduces the need for specialty processors like a DSP or blitter. The specialty processors are more efficient at what they specialize at but are less useful for more general purpose tasks. They usually end up sitting idle when there is no work for them while an SMP core can go do some number crunching.

Quote:

Minuous wrote: Why bother implementing this sort of thing when the OS3.9 API still isn't implemented, 13 years later?

It is easier to figure out what SMP would break now and program for it than complete full AmigaOS support and have to rewrite major parts when SMP is added later. This assumes that a workable and compatible enough solution to SMP can be found.

Last edited by matthey on 24-Aug-2013 at 05:06 AM.

@Minuous

Quote:

Why bother implementing this sort of thing when the OS3.9 API still isn't implemented, 13 years later? Maybe SMP is more fun for the devs to work on? Obviously they don't care about being useful for the users, or actually implementing the proper AmigaOS API.

Tell me one single thing AmigaOS3.9 has that current state OS4.1 lacks, and that can be considered "proper" by your standards please.

_________________
Cuida tus piedras gordas.

A1200/030 32Mb
A4000D
A1-X1000.