Wow, my honor to be talking to you, Linus.

Having stated that, I would like to point you to this document.

http://www-128.ibm.com/developerworks/library/pa-cell/

This article is written by the IBM developer who implemted the APU driver as a virtual file system on Linux. He clarifies.

> Since every thread that executes the SPU_RUN ioctl blocks for the duration of the ioctl system call,
> it can not interact with any other system resources at the same time, including other SPU contexts or
> files belonging to the context it is executing in. A single process can work with multiple SPU contexts,
> but to run on more than one SPU at a given time, the process needs to contain at least one thread for each
> running SPU context.
>
> Likewise, if the program communicates with the SPU code using mailbox access, it needs to create a new thread,
> for example, by calling fork or pthread_create. One of the threads then calls the SPU_RUN ioctl on the run file,
> while the other runs in an event loop on the mailbox files and potentially other file descriptors.

One APU requires one CPU thread that "kicked" it, one CPU cannot have two or more APU contexts in execution. Unless
Sony has another CELL OS with different programming model for games(which I doubt) this one CPU thread per one APU
rule stays.

While I understand your great wisdom, we are not dealing with X86 or any other traditional architectures. Since CELL was
custom-designed to suit the twisted mind of its paying customer, Kutaragi Ken, you have to see it from Kutaragi Ken(an
analog electrical engineer with no formal training in Computer Science or Computer Engineering. This is why his machines
are so wacky)'s perspective. And his perspectives are clearly different from yours and mine.

> Now, I actually thought the Cell would be a major pain to program for,

You are still right on that one. Nothing's changed.

> there is nothing fundamentally wrong with having Linux threads that can freely switch back and forth between the
PPE and a SPE.

Except for the fact that you would need to prepare two binaries for each function you have written, which comsumes time,
money, and more importantly memory. If this function was 100% in C/C++, then it wouldn't be so hard, just not very fast.
But most vector-related functions are written in assembly, which means two sets of assembly are required for each
processor ISA.

> On x86, you use a magic "iret" instruction to turn the CPU into a vm86 core, and on Cell you'd use "SPE resource
> scheduler" to turn a native-mode process into a SPE process, so it would certainly look very different in the
> details (and you could run seven SPE's at a time), but from a high level standpoint both cases really just have a
> system call to go into a new mode.

While I understand what you are proposing, I have not read anything like that from any of CELL-related papers. Furthermore,
there is a serious problem with memory.

Recall that each APU has only 256 KB of memory, of which 128 KB is used for program and 64 KB for presently executing
contex, 64 KB for prior or next context being read from or writing into memory.

And you cannot really fit a lot of program code in the space of 128 KB, just a few selected most-used functions that are
ported to APU ISA so that the thread residing in the CPU process space can jump process and now reside in the APU process
space. 95% of the time the thread cannot jump from the CPU process space to the APU process space because there is no
equivalent function available in the APU program memory. When there is one, then bingo the thread are ready to jump,
as long as the target APU is not under utilization by some other process. How effective is that? I have no idea. But my
gutt tells me this won't work.