Why is SMT (multicore) support hard for Amiga OS?

[psxphill]

There seems to be this idea that either the 680x0 is running, or the PPC is running. This is not the case. Both CPUs are running at the same time and only when they both attempt to access memory at the same moment is one physically blocked by another.

The PPC isn't running AmigaOS though. The hardware isn't the issue.
 
If you wanted to run two 68000's, then ExecBase would have to change.
Because of things like this:
 
struct   Task *ThisTask; /* pointer to current task (readable) */

But how to change it? It can't have two values at the same time. You could drop support for it, but then software would break. So it wouldn't be compatible enough.
 
The other alternative is to have a copy of ExecBase for each CPU. This seems like a good idea, except now you have duplicate information. You'll end up with two graphics.library and scsi.device, which isn't going to end well. You also have to overcome the problem that ExecBase is found by loading from $4, so you'd need an MMU on one of the CPU's at least.
 
Unfortunately AmigaOS 3.1 can't be changed in any meaningful way to offer multiprocessing for all applications. All you can do is add another scheduler, like powerup or warpos for new applications. It can't have memory protection either.
 
AmigaOS 4/MorphOS is another matter. I don't know enough about there schedulers, but if it followed the AmigaOS 3.1 design then they will have the same issues.

[psxphill]

Not in a WOS style implementation, where tasks are "transferred" cooperatively from one CPU to another, it wouldn't (as I said earlier, this isn't a serious option for many good reasons). In a true SMP implementation, of course it would.

You could also do it by running legacy applications on one CPU with ExecBase and have new applications that are designed for multiple CPUS run on a new scheduler.
 
However this violates both requirements.
1. It's not AmigaOS
2. It requires new applications.
 
Technically it would be little different to running AROS hosted on Linux.

[psxphill]

Whose requirements are those? What is AmigaOS, exactly? The kernel? The API? The coupled hardware? Regarding new applications, isn't that the point?
 
If the legacy kernel is itself a process under a new kernel--one that did all the magic necessary to support the legacy kernel as a process--then barring hardware incompatibilities, how would old applications know the difference? New applications could use the same APIs we use today, minus the bits we know to be "bad."

The question was "Why is SMT (multicore) support hard for Amiga OS?"
 
If all you want is a decent operating system and compatibility for amiga applications then winuae with a transparent desktop is probablt better for you. I'm sure someone has done this, not sure if it was official/finished though but basically it would look like the amiga windows are on your host operating system desktop. Also tcpip & filesystems can be hooked through to the native OS as well.
 
If you create a new OS that isn't compatible with anything else then you're going to struggle to get support.
 
Your only real hope would be to add support for multiple processors to AROS. As it's open source and most software for it is also open source then you can probably afford to break compatibilty.
 
It's still not trivial, because you have to get both cpu's running & make the changes to exec to support it.
 

isnt it still the same on win/mac/ix that apps have to be designed in order to take advantage of multiprocessor/multicore? so why makes it any difference on amiga in thi case.
 
at least i recall such about lightwave or photoshop earlier..

For one application to take advantage all you should need is to have multiple tasks (aka threads). Which is already possible on all versions of AmigaOS. Tasks are generally used if you need the UI to remain responsive while a process is carried out that may involve disk/network/other libraries that may not return immediately.
 
However two applications (each with a single task) on a multi cpu machine will also be able to take advantage.