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

[NorthWay]

Fair enough, but at this point I think we are looking at next-gen amiga systems, and I don't think an application recompile is too unreasonable if required.

Let me rephrase what I said:
The Forbid/Permit semaphore is a publicly readable and writeable kernel structure.
You are free to change the definition of how the OS works, but then you are on your own. AROS (very sensibly (IMNSHO)) decided to take 3.1 with warts and all and implement that first. When they are 100% done you can add New Stuff.

[Arkhan]

To: Amiga_Nut
<3: Karlos

[Fats]

To get things straight; I never wanted to imply that SMP is impossible on amiga-like systems. I just answered the question why I think it is hard.

Lots of interesting stuff here, I am learning a lot just sitting back and watching this for a bit =).
However, how does this even work on a single core system? Isn't access to these resources synchronized across tasks/threads already? Otherwise how do you know if whatever you have written to various memory locations is not in a half baked state when the other thread consuming it or also writing to it wakes up? Does the kernel have some intelligence when swapping tasks to ensure this somehow? I can't imagine that. I'd think this must be what the Forbid()/Permit() type of thing are exactly for if there is no other synchronization mechanism involved in these shared memory locations? I would think the kernel would not allow a task with a Forbid() in place to be swapped for this reason.

Exactly and a program in Forbid() state could rely on the fact that it is the only program in the system that is reading and/or writing to memory. On a SMP system this means that you have to stop all other programs on the other processors/cores.
You could implement this as a start and see what is gives for performance but given that Forbid()/Permit() is used over all the code in the libraries, drivers and user land code I think you will need to invest a lot of time to replace usage of Forbid()/Permit() with semaphores or other synchronization systems to get any benefit of SMP.
But like always I like to be proven wrong.

greets,
Staf.

[Karlos]

To: Amiga_Nut
<3: Karlos

^ top right: Product Placement Fail.

[Trev]

@Karlos

Haha. Maybe it's a suicide talisman--something she forgot to take with her.

Jumping in with my layman response: I like the sandbox idea. Run legacy and blacklisted software--second class processes--in an unprivileged, protected partition and devise a mechanism to marshal messages between first class and second class processes. Calls to privileged instructions could be caught and emulated within the sandbox. OS4 software should, hopefully, already be well-behaved. If not, it can be fixed and recompiled.

Personally, I don't care whether or not my OS4 box runs classic (680x0 or PPC) software, so long-term, I'd like to see support for legacy software disappear entirely. If you wanted to keep them, though, you could keep the first 32 bits of a 64-bit address space reserved for that stuff and create as many individual or shared sandboxes as the user wants. Think VM86 and DOS under OS/2 and Windows NT.

[Karlos]

I should point out that I'm in no way advocating a WOS like approach, which given my numerous references to it in this thread, people might think. The only reason I mention it at all is that it serves as a demonstration that general multiprocessing (ie two processors that can run code simultaneously, rather than one processor and a custom chip or FPU etc) already has a precedent of sorts.

True SMP is a different beast all together, of course.

[hardlink]

If anybody can get to the old usenet comp.sys.amiga discussions of this topic from > 15 years ago, they would be very informative. CBM itself, when in business, was looking into this when there were actually many full time people working on the OS, and Dave Haynie was looking into multi-CPU experimental hardware. He may have actually built a dual-68K board, I can't remember now. The basic problem was, as always, it would break too much existing software; of course, that was when there was commercial software still being written!

The 'original' Los Gatos Amiga crew were very much aware of the problems related to the 1983-1985 design decisions, and tried to apply what they learned in their next design, the 3DO operating system. I don't know if they made it SMP friendly or not, but it suffered the same ultimate fate as Amiga.

[bloodline]

@hardlink

That would be the CBM Gemini card, with two 68030s... IIRC Dave Haynie said that the software side of it was never completed. You are right that the team knew all too well the consequences of their design decisions... Jay Minor listed a few in his last interview

[dammy]

Actually Haynie's PIOS-One mobo was a quad PPC CPU.

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

[odin]

@hardlink

Jay Min*o*r listed a few in his last interview

Burn the heretic!

[Karlos]

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.

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.

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

[Trev]

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.

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

[wawrzon]

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

[Trev]

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

Sort of. A thread running on one of those operating systems may be scheduled on any available processor. The same could be done under Exec; however, Windows, Mac OS, and Linux prevent unassisted user code from modifying kernel structures, suspending scheduling, and disabling interrupts. Many (most) Amiga applications (read: programmers) know too much about the kernel, and rather than using a solid and safe design, they manipulate kernel objects directly.

As most Amiga users would rather run software written in 1990 than software written today, these unsafe programming practices pose a problem for innovation.