[Cbe-oss-dev] Call/return from PPE to SPE functions

[Arnd Bergmann]

On Tuesday 29 May 2007, Brian Watt wrote:
> > On Tuesday 29 May 2007, Brian Watt wrote:
> >
> > You could do it in theory, but it would be horribly inefficient. The 
> > only
> > time that you can set SPE general purpose registers is when the context
> > is saved in kernel memory. Making a function call to the SPU this way
> > basically means having more overhead than starting the program in the
> > first place.
> 
> Hmmm, there is no "starting the program in the first place", instead the
> SPU context would be created, and the program loaded once per 
> thread-of-control,
> then one or more SPE functions would be called as requested by the PPE 
> program
> using spe_context_run. So I don't see why there would be any more overhead 
> than
> today's starting of a main function or a SPE_RUN_USER_REGS function.

The fundamental difference is that a context is created in saved state,
and then loaded into an SPU when you first call the spe_context_run
function.

The registers are only accessible in saved state, so in order to
change them, the context needs to be suspended and written back
into kernel memory.
 
> Today there is a set_regs function in the run.c file that is invoked by
> the spe_context_run. This function opens the register spufs file and 
> updates
> it with the register values. This could still be used for function 
> invocation,
> although I'm sure that it is an computationally expensive way to update 
> the
> registers. Possibly a direct program state approach might be better, but
> I've not investigated this yet. That is another reason I'm taking about
> it here and learning about the options.
> 
> To allow the return of the result in a register, a new get_regs function
> would need to be added to run.c which is invoked when the completion stop
> and signal (0x2000) is received.

The registers are not accessible through any memory map, neither in the
kernel, nor through problem state registers.
The only way to set them is to run code on the SPU that actually reads
and writes them from/to memory, and copy that over.
 
	Arnd <><