32-bit vs. 64-bit PPU code

[ouasse]

Hi,

My question may not be specific to the ps3, it's more generally aimed at development on the Cell BE processor. But as my Cell BE development platform is a PS3, I'm asking on this forum ;)

My question is simple : are there things to know when programming the spe's when the ppe is running 32 bit code ? All the documentation I've read so far from IBM and other contributors has been written supposing the PPU runs in 64 bit mode, which would suggest that programming in 64 -bit mode would be recommended in general.

My problem is that I'm running a 32-bit Debian system, and most libraries I'm using in different projects (lam/mpi, libsdl) have been compiled in 32 bit mode. I have found a way to manually force the installation of ppc64 packages, but it's quite dirty, and although LAM/MPI only consists in a limited number of packages, libsdl is not the case, and has a number of dependencies.

Some trial code I've done in 32 bit mode runs in a rather random extent : some DMA transfers between ppe ram and spe local store work, while some don't (infinite process hangup, needs to be killed by SIGINT). I always respect the 16 byte aligment rule, as well as transfer size which is obviously quadword-aligned. The code generally works when compiling the PPE code in 64 bit mode.

Does any of you have experience about these issues ? Any indication would be greatly appreciated.

[IronPeter]

>Some trial code I've done in 32 bit mode runs in a rather random extent : some DMA transfers between ppe ram and spe local store work, while some don't (infinite process hangup, needs to be killed by SIGINT).

Transfer pointers from PPE to SPE as unsigned __int32. dma_put(get) will take correct unsigned __int64 addresses.

[ouasse]

many thanks IronPeter !

Indeed, casting 32-bit pointers to unsigned __int64 performs some sign extension of addresses. Which was obviously not what I needed.

[ouasse]

Does anybody know about performance differencies between 32-bit and 64-bit mode ?

[unsolo]

Aparently there is a bug that allows faster context switching for 32 bit .. however i have been told by kernel devs this is a bug and you should not rely on this as a permanent gain..
However 32 bit programs have a sligtly lesser memory impact which leaves you with very little but some gain on the memory side.

when it comes to 32 bit pointers the one of the following should suffice to ensure 32 and 64 bit compatibility

Code: Select all

#ifdef __powerpc__
	#ifndef __powerpc64__
		
		#define spu_mask(val) ((uint64_t) ((uint32_t) val))
	#else
		#define spu_mask(val) ((uint64_t) val)
	#endif
#endif

or

Code: Select all

uint64_t spu_mask(void* val) {

             return ( (uint64_t)  ( (unsigned long) val) );
}

should also do the trick

And make sure you use unsigned long long or uint64_t on all the spu dma commands and you avoid it blowing up on you.