[Cbe-oss-dev] [RFC] Reading Local Store base address from SPU using stop-and-signal with kernel support

[Cédric Augonnet]

Hi all,

Sometimes, the SPU needs to know where its Local Store is mapped on
main memory. The issue is that the user would have to somehow
explicitly supply that information to the SPU as far as i know.
Therefore a library needing that base address would hardly get that
information.

I would have liked to have your opinion about using a stop-and-signal
receiving some implicit support from the kernel in order to get it.

This is doable using the same approach as for system calls used from
the SPUs : the argument supplied during the stop-and-signal call would
be specific to that functionality (as it is already the case 0x2104
for syscalls). The kernel would recognize such a specific case and
handle it in consequence.

Here is a draft of the patch that would normally make it possible :
http://perso.ens-lyon.fr/cedric.augonnet/Kernel/spu_get_ls.patch

Please note that this patch could *not* been tested yet since I don't
have available hardware. But this shows the basic outlines of the
proposition.

To make it clearer, I also wrote a sample of a SPU code intended to
show how this functionnality could be used so that the SPU could get
the LS base address transparently.
http://perso.ens-lyon.fr/cedric.augonnet/Kernel/sample.c

So my questions are :
1/ Can such a stop-and-signal argument be reserved for so specific a
purpose, as it was done with syscalls ?

2/ Should we rather be able to retrieve the spu identifier using that
same technique, and then make use of a couple of DMA transfer to
explicitly fetch the base address from the PPU, provided the speid ?

I'm aware that providing such functionnalities through macros on the
SPU might really hide the possibly huge cost of such a stop-and-signal
call, but if the programmer is aware of such a cost, can't it make spu
library simpler to write?

Perhaps this is silly proposition, I don't know, thus I just keep hearing
for any comment about it.

Best regards,
Cedric