since jason has now openly revealed it on amiga.org i think i may be allowed to quote him here:

Quote:

Quote: 'Silly-SMP' is a project to determine "What are the minimal changes needed to AROS to support 'full' SMP? Is it even possible?" I had a bit of insight (misguided, and missing a lot of details, but I think pointing in the right direction) and I decided that, instead of just talking about possible design ideas, that "the code will prove out". As of now, I can get a simulated dual-CPU system up on AROS hosted on Linux x86_64 (25% of the time - the other 75% of the time it crashes on boot). Is it ready for prime time? No. Is it ready for inclusion in AROS ABIv1? No. Is it even ready for testers? No. This is Research with a capital 'R'. But that '25% of the time' _does_ show that a full SMP system on AROS is possible. Lots of debugging, testing, more experimentation, etc etc. is needed. But it is possible. So far, the only 'user visible' changes are that some fields in SysBase are NULL or zero, that previously had values: * ThisTask is NULL (this is now per-CPU) - You should have been using FindTask(NULL) anyway! * Elapsed/IdleCount/DispCount is 0 (this is now per-CPU) - We (AROS) need to make an API to retrieve this per-CPU * AttnResched/SysFlags changed - But you shouldn't have been using this anyway! Strict priority scheduling is (currently) not strict at all, and I and Michael Schultz are experimenting with what that breaks in application-land, and if we really need to fix it. The 'm68k changes' you see in the repository are for making sure unicore m68k still works - not for adding m68k multicore support. But if someone *did* make a SMP m68k processor, there are MMU tricks that can be used to 'magically fix' the altered SysBase fields for pre-existing m68k programs - so compatibility is with AmigaOS 3.x is still possible. For you Morphos/AmigsOS developers - if you would like to bounce ideas off of me with respect to adding SMP to your operating system of choice, feel free to contact me, or just silently watch my 'silly-smp' branch on gitorious.org AROS (in my humble option) is here for the betterment of all AmigaOS-alike operating systems. We blaze the trail to the unexplored lands.

Last edited by wawa on 22-Aug-2013 at 04:43 PM.
Last edited by wawa on 22-Aug-2013 at 12:31 AM.
Last edited by wawa on 22-Aug-2013 at 12:30 AM.

Nice, it's good to see AROS moving this forward like this.

I'd personally like to see AROS as a modern implementation of Amiga OS and not be so concerned about 3.1 compatibility built into the core.

It would probably make more sense to build 3.1 compatibility into some kind of translation layer which is only used when running 68k software, I think OS4 already does something like that?

Finally at least some sign of progress... Now if only it had memory protection, proper hardware support and software it would actually be something i consider using as a main system.

Great news!

AROS may get SMP before AmigaOS 4.x or MOS. It would be interesting to see AROS PowerPC with SMP on that expensive x1000 running 50% faster than AmigaOS 4.x. Free AmigaOS with SMP (AROS) vs AmigaOS 4.x with no SMP and $$$. Hmmm.

@matthey

Quote:

AROS may get SMP before AmigaOS 4.x or MOS.

With backward compatibility? That would be great!

Quote:

It would be interesting to see AROS PowerPC with SMP on that expensive x1000 running 50% faster than AmigaOS 4.x.

There is AROS port for X1000?
Speed increase with SMP is application dependend - eg. nearly 100 % in Blender or OGR vs 60 % for video playback (dual core) etc. Sure, any speed increase is always good.


Many AROS and MorphOS developers mocked Hyperion when OS4 multicore project was semi-announced few years ago, they said it is impossible. It seems it is not that impossible at all and Hyperion was right.

@pavlor

Quote:

With backward compatibility? That would be great!

as you can read from jasons post its all a big experiment, since aros is a research operating system, so it will still have to be proven pratically possible. the attempt is towards that. good thing is aros needs to care about backwards binary compatibility only on 68k.

Quote:

There is AROS port for X1000?

there is no. i dont mind either way, to be honest.

Quote:

Speed increase with SMP is application dependend - eg. nearly 100 % in Blender or OGR vs 60 % for video playback (dual core) etc. Sure, any speed increase is always good.

sure, currently the aros "silly smp" gives even less punch all in all.

Quote:

Many AROS and MorphOS developers mocked Hyperion when OS4 multicore project was semi-announced few years ago, they said it is impossible. It seems it is not that impossible at all and Hyperion was right.

it was morphos users, in particular one of them comes to mind. i dont recall any such opinions out of aros camp, on the contrary, some aros smp foundations were laid out long ago by kalamatee if memory serves me right. different concepts have been considered since them, now, jason just strided to action few days ago and here are the first results;)

btw i remember a late discussion on aorg, where staf (fats) most prominently opposed takemehometograndma opinion that smp is not possible. i was following this subject rather closely.

and now to hyperion being right or not, is rather secondary issue. you can talk and promise about everything, what counts is getting it done actually.

Last edited by wawa on 22-Aug-2013 at 11:11 AM.
Last edited by wawa on 22-Aug-2013 at 11:11 AM.

@wawa

Quote:

what counts is getting it done actually.

Exactly.

@pavlor

also i think its not the actual problem to get smp running under amiga circumstances (permit/forbid and the like) but to gain actually additional speed out of it.

I know its off-topic but at least classic AmigaOS has some kind of multicore support when it runs with winuae. My cpu monitor shows that WinUAE more or less uses all cpus. So maybe we just have to write an emulator

@Beeblebrox

Sure, but that just shows Windows supports muticore to emulate the Amiga. Amiga OS software running under it doesnt use multiple cores :)

@pavlor

Quote:

Quote: AROS may get SMP before AmigaOS 4.x or MOS. With backward compatibility? That would be great!

Since AROS is binary compatible with nothing (except 68k but they are single core systems) there is more freedom to actual implementation. And of course existing software can be adapted to new standards.

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

@wawa

My suggestion is to rename the thread to "aros researching smp" or "aros experiments with smp". The current one suggest it is already done.

_________________
https://www.axrt.org

@deadwood

i dont think it suggest that it is done as i have not used present perfect, but to avoid misunderstandings i corrected the title accordingly.

double post..

Last edited by wawa on 22-Aug-2013 at 05:09 PM.
Last edited by wawa on 22-Aug-2013 at 05:08 PM.

@deadwood

+1

That someone even bothered to try SMP while trying to keep (partially) compatibility is great. On the other hand the current state seems to be some kind of hack, at least that what a quick look made me think. Couldn't see any design documents or even implementation notes but that is maybe me being blind...

So here's some guessing: the protection of the forbid/disable memory areas are using paging which would mean that all accesses to page 0 will trigger a costly page fault that then have to compare the fault address to the relevant protected location for each.

Another way to do the same that should (if it works) be a bit less expensive would be to use two debug registers (one for forbid and one for disable) set to trigger on writes. This assumes that the debug logic snoops accesses from other processors which I never have tested. If so any access to any other area in page 0 will not trigger any exception but writing (=modifying) the relevant locations will. The handler will be easier to write too.

@megol

The designs are shared on AROS development mainling list.

Jason also opened a discussion thread here:

http://www.amiga.org/forums/showthread.php?t=65753

_________________
https://www.axrt.org

@megol

Quote:

So here's some guessing: the protection of the forbid/disable memory areas are using paging which would mean that all accesses to page 0 will trigger a costly page fault that then have to compare the fault address to the relevant protected location for each.

Why so complicated? With x86_64 we can send IPI (Inter Processor Interrupt) to signal

a) All CPU cores but this
b) All CPU cores including this
c) This CPU core
d) A CPU core of our choice

using the APIC bus. It's more than enough to provide satisfactory degree of communication between all CPU cores.

Last edited by michalsc on 22-Aug-2013 at 05:52 PM.

This is a tad interesting to see where it ends up, well done so far all you AROS guys !


;)

Last edited by Manu on 23-Aug-2013 at 05:45 AM.

_________________
AmigaOS or MorphOS on x86 would sell orders of magnitude more than the current,
hardware-intensive solutions. And they'd go faster.-- D.Haynie

@michalsc

Quote:

michalsc wrote: @megol Quote: So here's some guessing: the protection of the forbid/disable memory areas are using paging which would mean that all accesses to page 0 will trigger a costly page fault that then have to compare the fault address to the relevant protected location for each. Why so complicated? With x86_64 we can send IPI (Inter Processor Interrupt) to signal a) All CPU cores but this b) All CPU cores including this c) This CPU core d) A CPU core of our choice using the APIC bus. It's more than enough to provide satisfactory degree of communication between all CPU cores.

I don't see what that have to do with my post? Sending IPIs are simple, detecting when to do so _efficiently_ is harder.

Edit:
Whether using debug registers or IPIs are more efficient is something that have to be measured. It's still possible to use debug registers with IPI where the "forbidder" is trapped and then sends IPI to the other processors. But then the critical path is two exceptions (first the debug one, then the IPI for all other processors). If the debug registers snoops writes then this is reduced to one exception that's executed in parallel for all processors/cores.

Last edited by megol on 23-Aug-2013 at 10:04 AM.

@itix

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.

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

Last edited by NutsAboutAmiga on 23-Aug-2013 at 10:16 AM.

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