Will OS4 have SMP after all

[bloodline]

And what it will be like ?

I ask because I want to know ... :smack:

I doubt OS4 would ever have SMP as there isn't really any proper SMP PPC hardware... AROS runs on SMP hardware and has run into the problems with the AmigaOS design that isn't really suited to SMP (and trying to make it work might actually be slower than a single CPU), but AROS is an open source research OS and as such devs have proposed various solutions which can be tested. Many of the design issues have been deprecated in AROS (for example the forbid() function) and exist only for compatibility with older software.

[bloodline]

It was multi-processor ready and it used 060 and PPC at the same time ...

It's just that all the educated people claimed that there is no way to do true
SMP support without basically writing new Os  (like TMHG said once) ...

But I guess there is nothing a man can't achieve so I'm open minded and
would like to hear how they plan to do it ...

I don't think AOS4 ever used both the 68k and the PPC at the same time. PowerUP and WarpOS used both at the same time, but that's not SMP, that's AMP (Asymmetric Multiprocessing)...

[bloodline]

@fats
interesting, how is the situation on aros? is there also as heavy usage of forbid/permit or has it been replaced with something else at least partly, im curious?

AROS encourages the use of semaphores to lock resources.

[bloodline]

Just a thought but couldn't forbid calls be replaced with forbidx calls??

For example forbidx would only affect the processor the task was running on.

Or forbid1 forbid2 forbid3 forbid4 (1 for each core)

People once said dos programs could never multitask. Of course they could, just needed the right way to have a master program timeslice and handle them.

Just saying, there has to be a way to fix the amiga smp problem, even if programs need to be slightly fixed and recompiled.

When I look at all the ways amiga programmers pushed the limits with demos, I wonder why people are so quick to say ANYTHING can't be done by amiga programmers...

Once a task has called forbid(), it expects to have the entire machine to itself... If any other task were still running (on another CPU), they could both be using the same data structure (AmigaOS has a shared memory model)!

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

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

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

[bloodline]

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.

A working SMP implementation wouldn't break compatibility

[bloodline]

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

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

[bloodline]

What if a modified exec was running on top of a modified Linux kernel that enabled SMP by distributing Amiga processes across various cores?

A kind of Amithlon on steroids?

That would be one solution

[bloodline]

Not neccessarily.  Who knows what they would do and how they would do it?

There are many ways to skin a cat as you know Matt.

You are, of course, quite right. I'm just remembering how Ralph explained the ABox/QBox separation to me. The idea was to keep the legacy 68k/PPC stuff in the Abox and all the new stuff in the QBox.

[bloodline]

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

UAE on AROS and native AROS apps shared a graphical user interface too... That was kind of the point

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

The advantage of the 68k emulation in AOS4 and MOS is that the 68k and PPC apps live in the same environment and can share libraries etc... It is only possible because the 68K and PPC are big endien...

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

I don't think you realise that the AROS UAE integration is supposed to be pretty seamless to the user... You might never know UAE is actually running!!

[bloodline]

A clone of Trance with seamless byte-swapping would be nice.  Shame Emumiga never got off the ground.

I know, I really liked the whole Emumiga concept, but it was a complex idea... I had a look at resurrecting it myself, but it was out of my league... Especially with how little time I had.

[bloodline]

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.

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

[bloodline]

Well, with AOS4 Classic you do because the hardware is there.

That's a little off topic, AOS4 classic is never going to have SMP