| View previous topic :: View next topic |
| Author |
Message |
ouasse
Joined: 30 Jul 2007
Posts: 90
Location: Paris, France
|
 Posted: Sun Feb 10, 2008 8:39 pm Post subject: 32-bit vs. 64-bit PPU code |
 |
|
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. |
|
| Back to top |
|
 |
IronPeter
Joined: 06 Aug 2007
Posts: 207
|
| Posted: Sun Feb 10, 2008 11:11 pm Post subject: |
|
|
>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. |
|
| Back to top |
|
|
ouasse
Joined: 30 Jul 2007
Posts: 90
Location: Paris, France
|
| Posted: Mon Feb 11, 2008 7:40 am Post subject: |
|
|
many thanks IronPeter !
Indeed, casting 32-bit pointers to unsigned __int64 performs some sign extension of addresses. Which was obviously not what I needed. |
|
| Back to top |
|
|
ouasse
Joined: 30 Jul 2007
Posts: 90
Location: Paris, France
|
| Posted: Tue Feb 19, 2008 10:54 pm Post subject: |
|
|
| Does anybody know about performance differencies between 32-bit and 64-bit mode ? |
|
| Back to top |
|
|
unsolo
Joined: 16 Apr 2007
Posts: 155
Location: OSLO Norway
|
| Posted: Sun Feb 24, 2008 9:31 pm Post subject: |
|
|
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: |
#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: |
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.
_________________
Don't do it alone. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
