Quote:

The original Amiga exec had "multicore" support in the form of coordinated access to coprocessors. Conceptually, using the Cell (or a network chipset or a video chipset) is no different.

There's no way you can take full advantage of today's multicore processors with current (20 years old) exec...

_________________
http://www.warpdesign.fr/

@Leo

I suppose it depends on how those cores are implemented. In the case of the Cell, the SPEs are used in a manner similar to other external devices. Exec wouldn't be running on them--that's what the PPU is for.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev

Quote:

Trev wrote: @Leo I suppose it depends on how those cores are implemented. In the case of the Cell, the SPEs are used in a manner similar to other external devices. Exec wouldn't be running on them--that's what the PPU is for.

Absolutely. The original Amiga chipset was a set of co-processors which good old exec managed very effectively. Given that the Cell processor is designed to have the OS running on the PPU, and the SPEs are used as co-processor, taking advantage of this would be no different from taking advantage of the Amiga chipset, or a graphics card's 3D processor.

@Leo

One minor nit-pick; my understanding is that Amiga OS 4's ExecSG was built from the ground up, so it's not exactly the same as the 20 year old exec. Of course, it's based on the API of the original exec, so it's not ready for Symmetrical Multi-Processing (SMP), yet.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans

Quote:

One minor nit-pick; my understanding is that Amiga OS 4's ExecSG was built from the ground up, so it's not exactly the same as the 20 year old exec. Of course, it's based on the API of the original exec, so it's not ready for Symmetrical Multi-Processing (SMP), yet.

Most of the app-level entry into exec is fairly abstract--add a task, signal a semaphore, open a library, etc. If the scheduler were made aware of SMP (or ASMP, if you wanted to build a software abstraction on top of something like a Cell for general purpose use), then it would handle all the difficult bits: task affinity, context switches, etc. If software developers have been following "the rules," their source code should work well in the new world with minimal changes.

That's my lay theory. For all I know, ExecSG is unextensible spaghetti code. The folks responsible don't strike me as the types to design or write terribly bad code, though.

EDIT: The rest of the hard bits--cache coherency, synchronization, etc.--are being dealt with industry-wide. It's been difficult for many to make the leap from consuming resources (CPU cycles, memory, I/O time, etc.) to conserving them via smart parallel algorithms. Having a completely preemptive scheduler and coprocessor-based system from the start should have given Amiga developers a head start.

Last edited by Trev on 24-Apr-2009 at 10:24 PM.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev

IIRC, they had SMP and full memory protection in the back of their mind as they wrote it. My understanding is that the problem with SMP is more that forbit()/permit() would be a real performance killer since all cores would have to be stopped. Any direct access to internal structures would have to go (one of the reasons to use forbid()/permit()) as does forbid()/permit().

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans

I think if you identify the areas where Forbid()/Permit() pairs are used most often, you could implement workarounds for specific cases and limit the scope of Forbid()/Permit() in the general case, e.g. only prevent task switching between threads/tasks that are children or peers of the current task. If a child task must prevent a parent or higher level task from modifying data, then a synchronization technique more elegant than Forbid()/Permit() needs to be used.

Why are Forbid() and Permit() still in use in OS4, apart from compatibility with OS3 applications (which belong in a controlled penalty box)?

A few simple (yeah, I know it's not really that simple) changes in thinking go a long way to making the implementation of SMP and memory protection easier.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev

Quote:

Trev wrote: Why are Forbid() and Permit() still in use in OS4, apart from compatibility with OS3 applications (which belong in a controlled penalty box)?

They're needed until the sandbox for old apps is created and the API has removed all instances in which this was needed. It's a matter of progression.

First, a PowerPC kernel with 68k emulator was needed so that 68k software and drivers ran; next, each 68k library/device/whatever had to be migrated to PowerPC. All this while new enhancements were added. Given that these tasks are now pretty much done, now would be a good time to take the next step and construct that sandbox so that API modernization can begin.

Quote:

A few simple (yeah, I know it's not really that simple) changes in thinking go a long way to making the implementation of SMP and memory protection easier.

Like I said, I'm pretty sure that they had SMP and memory protection in mind as ExecSG was being written. One of the advantages of library interfaces is that a future version of exec could have a version 2 IExec without forbid()/permit().

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Trev

Mutexes were added into AmigaOS4.0 final update almost two years ago. So software developers have had plenty of time to replace forbid-permit's with mutexes.

_________________
Rock lobster bit me. My Workbench has always preferences. X1000 + AmigaOS4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." -Seymour Cray

@Tomppeli

? The most common use of the classic SignalSemaphore is as a mutex, e.g.:

TaskA()
{
ObtainSemaphore(&sem);
/* do something */
ReleaseSemaphore(&sem);
}

TaskB()
{
ObtainSemaphore(&sem);
/* do something */
ReleaseSemaphore(&sem);
}

I presume OS4 mutexes fix the problems associated with SignalSemaphore objects? In particular, fud like this:

Forbid();
if ((sem = FindSemaphore(name))) {
ObtainSemaphore(&sem);
}
Permit();

... which gets rid of those nast Forbid()/Permit() pairs.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev

It could be a case of semaphores being overkill for something that only requires a mutex. I looked at the code for pthreads on windows recently, and their rwlock implementation (roughly equivalent to Amiga OS semaphores) actually used multiple mutexes internally in order to get both shared and exclusive locking. A mutex is simpler, probably faster, and makes it easier to do things such as temporarily upgrading the priority of a thread if it holds a mutex that a higher priority task is waiting for.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Tomppeli

Quote:

Mutexes were added into AmigaOS4.0 final update almost two years ago. So software developers have had plenty of time to replace forbid-permit's with mutexes.

Semaphore can only be used where it has not bean used before, or where it does not conflict forbids.

1) The rules for modifying system data has not been defined yet.
Programs that use Semaphore ask for premonition to modify, but the system does not yet know what your asking for, this some that has to be defined.

2) Old programs are incompatible whit Semaphores, because they are based on the idea that multitasking is off, while modifying data, but this not the case, a program that does use Semaphore might be modifying some thing, when the old program turns off multitasking.

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

@Hans

I'm not sure that a mutex is much faster than a semaphore on Windows. They both make trips into kernel code. (A critical section should be faster, but it's process-specific.) I know that's not what you were getting at, but I have a feeling the mutex and semaphore implementations on Windows share a lot of code, i.e. a mutex implemented using a binary semaphore.

Does OS4 deal with the priority inversion problem today, or is that still a pending feature?

EDIT: Check out slim reader/writer (SRW) locks in Windows. Sound familiar?

Last edited by Trev on 25-Apr-2009 at 02:58 AM.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

Quote:

IIRC, they had SMP and full memory protection in the back of their mind as they wrote it. My understanding is that the problem with SMP is more that forbit()/permit() would be a real performance killer since all cores would have to be stopped. Any direct access to internal structures would have to go (one of the reasons to use forbid()/permit()) as does forbid()/permit().

The problem is people didn't think about it when they wrote Exec back in 1985. So this doesn't change anything they are thinking about it. The design doesn't allow it without bad hacks (and even with...).

And let's say SPU can be used as "coprocessor", what would you use SPU for in current AmigaOS software ? Tell me, I'm curious...

Now, while switching to a faster processor you immediatly take benefit of the speed (emulators, games, videos, heavy web pages, overall speed), with things like SPU you have to write your software to take advantage of it. Seeing how difficult it is on the PS3 for developers to take advantage of it how do you think the (very few) Amiga developers will handle it ? How do you think people that can barely make a make install to "port" some SDL game will handle it ?

Really there's currently no point in having the OS ported to this kind of environment. No use for the users, no use for the developers, and no use for gaining new users.

_________________
http://www.warpdesign.fr/

@Trev

Quote:

Trev wrote: @Hans I'm not sure that a mutex is much faster than a semaphore on Windows. They both make trips into kernel code. (A critical section should be faster, but it's process-specific.) I know that's not what you were getting at, but I have a feeling the mutex and semaphore implementations on Windows share a lot of code, i.e. a mutex implemented using a binary semaphore.

I was talking about the pthreads implementation for windows, not the windows OS itself; otherwise I wouldn't have access to the source, would I?

Quote:

Does OS4 deal with the priority inversion problem today, or is that still a pending feature?

No idea.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Leo

Quote:

Leo wrote: Quote: IIRC, they had SMP and full memory protection in the back of their mind as they wrote it. My understanding is that the problem with SMP is more that forbit()/permit() would be a real performance killer since all cores would have to be stopped. Any direct access to internal structures would have to go (one of the reasons to use forbid()/permit()) as does forbid()/permit(). The problem is people didn't think about it when they wrote Exec back in 1985. So this doesn't change anything they are thinking about it. The design doesn't allow it without bad hacks (and even with...).

Eliminating forbid()/permit() would entail a compatibility break. Some compatibility breaks are inevitable in order to overcome these limitations; hence the need for a sandbox so that old apps can play happily. Seeing as you've been advocating a complete compatibility break, I thought that you wouldn't have a problem with this.

Quote:

And let's say SPU can be used as "coprocessor", what would you use SPU for in current AmigaOS software ? Tell me, I'm curious...

Well, let's see. On the PS3, I believe that Linux uses it as a substitute GPU. That could be useful. My understanding is also that it would be quite effective for video/image/audio codecs. The real advantage would be for new software though.

Quote:

Now, while switching to a faster processor you immediatly take benefit of the speed (emulators, games, videos, heavy web pages, overall speed), with things like SPU you have to write your software to take advantage of it. Seeing how difficult it is on the PS3 for developers to take advantage of it how do you think the (very few) Amiga developers will handle it ? How do you think people that can barely make a make install to "port" some SDL game will handle it ?

Wow, such a low opinion of Amiga developers. You might want to check out a company called RapidMind, and also a standard called OpenCL. That's what I would use if I were trying to take advantage of the SPUs, but then, I'm not the one wondering what the heck you would use it for.

Quote:

Really there's currently no point in having the OS ported to this kind of environment. No use for the users, no use for the developers, and no use for gaining new users.

But it is useful to developers. However, you're such a negative person that I doubt that you could see this.

You were originally arguing that Exec wouldn't be able to use SPUs; now you're suggesting that there's just no point.

Hans

Last edited by Hans on 25-Apr-2009 at 08:03 AM.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Leo

Quote:

The problem is people didn't think about it when they wrote Exec back in 1985.

But they DID think about it when they rewrote the Exec in 2001-2003. The new features are used by some rewritten components.

_________________
cheers
tony

Hyperion Support Forum: http://forum.hyperion-entertainment.biz/index.php

@Leo

Quote:

And let's say SPU can be used as "coprocessor", what would you use SPU for in current AmigaOS software ? Tell me, I'm curious...

Decoding FullHD h264 video? :)

@Leo

Quote:

The problem is people didn't think about it when they wrote Exec back in 1985.

No, they did think about it; they just didn't have an elegant solution to the problem on a system without memory protection. Like anything else, developers ignored the standards, the warnings, and even the Beware of Dog sign. So, we're stuck with a legacy of software that used calls it really shouldn't have been using. (Of course, the documentation often advocated the use of Forbid()/Permit() around access to public objects, and the designers could have solved that problem using their own public APIs, i.e. shared read semaphores to prevent removal of public named objects--but they didn't.)

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@COBRA

Quote:

Decoding FullHD h264 video? :)

Yes! But if you're running on a PS3, it's kind of redundant.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

Quote:

Eliminating forbid()/permit() would entail a compatibility break. Some compatibility breaks are inevitable in order to overcome these limitations; hence the need for a sandbox so that old apps can play happily. Seeing as you've been advocating a complete compatibility break, I thought that you wouldn't have a problem with this.

I have nothing against it. But I don't see the use of taking the time to write a sandbox right now... A sandbox approach should have been taken back in 2002 (yeah, that's the MorphOS way), not now...
And, btw, breaking bad written applications would help eliminating bad written apps and give better habbits to users&developers... No one ever did that at Commodore. That's a problem.

And I don't have any bad opinion about Amiga developers. It just appears that a lot of people which are not real developers try to port applications, without really knowing what they do. Because no one else does it,... I have nothing against these people. And guess what ? I also did it... cause no one else was here to do it. But the thing is that I don't see these people writing applications taking advantage of SPUs. I wouldn't see myself do it either.
That said, they are of course also competent developers. Never denied it.

I don't see a point in having an AmigaOS run on this hardware, nor do I see current OS handle all these "coprocessors" efficiently and without a hack. That's it.

_________________
http://www.warpdesign.fr/