SOURCE

Link to IBM]
More info
[url=http://en.wikipedia.org/wiki/Octopiler]Wikipedia[url]

According to IBM's website this compiler should take care of all optimization currently required for the cell processor, making porting to psubuntu easier and above all, way faster!

But do you really think that IBM will port it on ubuntu ?

Good point, having to compile on another system wouldn't a big deal though? or isn't it that easy?

Well, i have tried to convert rpm packages to deb packages with alien. ( Note that there is NO source of IBM cell-sdk at all. ) So what i had: plenty of dirty, bleeding packages from ibm cell-sdk 3.0, without dependency. Most of them were installed successfully ( about 30 ppc.rpm and noarch.rpm using dpkg ), while 2 packages have conflicts with ubuntu cell-sdk and 3 packages say: broken pipe. Opt directory was now full of files. I have used about 10 cell optimized sources and resault is: FAILED.

I spent a lot of time installing IBM's XL compiler to install on Ubuntu (9.04) on my PS3. I am not very experienced with packages, so I did a lot of manual installation. I'm afraid that I did not take detailed notes of the process (which I worked on in my free time over several weeks), so these instructions are just an outline of what needs to be done.

0) Go to IBM's web site and download (1) Cell BE SDK and (2) a 60-day evaluation of IBM's XL Compiler for Cell BE. I recall that #2 was difficult to find.
1) Installation. The first step was to extract all of the needed files out of the .rpms. I used Alien to just dump the package contents to a simple directory. The directories structure maps simply to /opt/ibmcmp. A lot of merging has to be done for each of the packages (they all map to /opt/ibmcmp).
2) Configuration. The XL compiler needs to be configured to work with your gcc environment. The perl script "xlc_configure" is used to do this. However, the script is only written for RHEL, Fedora, and OpenSuSe (undocumented support?). You have to hack this script to install on Ubuntu. There are functions like isFedora() that you can comment out or hijack to work for you. The script has undocumented parameters -v and -vv for verbose debug output. Run the configuration script with debug, find the error, hack it away, repeat.
3) Update your PATH and LD_LIBRARY_PATH for XL binaries and libraries.

Notes and Pitfalls:
1) DO NOT install ppu/spu-gcc based upon gcc 4.3 (available from the Barcelona Cell BE site). XL for Cell BE appears to be incompatible (xlc bails when trying to process some __attribute__ tags). I was unable to compile any C++ files that included common headers like iostream and vector. Just use the ppu/spu-gcc binaries based on gcc 4.1 which are available through the normal Ubuntu repositories. (I tried to get the 4.3 and 4.1 packages to coexist with symbolic links, but xlc still found the 4.3 binutils files causing the problems. Perhaps the 4.3 packages can be installed after xlc is configured?)
2) In xlc 9.x, the octopiler was an experimental package that installed the "ssc" (single source compiler). In 10.1, ssc is no longer experimental and is now known as cbexlc and cbexlc++. If you want to enable the SPU magic, run cbe* with "-qipa=overlay -qsmp". These parameters cause cbe to try to offload as much work to the SPUs as possible. Use different options if your program uses OpenMP (and you want the OpenMP threads to be offloaded onto the SPUs).
3) Regarding practicality and general use of xlc: It does not look good IMHO. I have been trying to get xlc to compile snes9x-gtk (an SNES emulator) and have learned the following:
* The PS3 is extremely memory starved and XL likes to use memory. You may need as much as 5GB of swap space to perform interprocedural analysis (ipa) optimizations (enabled at -O4 and above). If you use the SPU cbe magic, you must always do ipa (at least during linking). I gave up trying to link cbe-compiled snes9x-gtk after the linker had been running for 24 hours. I was afraid that all the swapping was going to kill my hard drive!
* Compiling and linking can take hours due to swapping. So free up as much memory as possible while compiling (ex. > sudo /etc/init.d/gdm stop).
* xlc is not able to compile everything that gcc can. So if you find a file that cannot be compiled with xlc, just use gcc to create the needed .o file (or do some code refactoring). xlc can be used to link gcc-generated .o files and visa versa (except if cbe SPU magic is involved).
* Lumping code into _shared_ libraries (*.so) can reduce the load on xlc during the link phase. However, cbe .o files with SPU magic cannot be compiled into a shared library.

So where am I on my snes9x experiment? I was able to use ppuxlc to (manually) compile most of the snes9x files and I supplemented the gaps with gcc. I was able to use ppuxlc on the code hotspots (with minor refactoring of gtk_display.cpp), so I am not worried about gcc inefficiencies. However, all this work only squeezed out an extra frame per second when running in fullscreen mode since all this code still runs on the ppu (and performance still sucks at ~15fps). I tried many different methods to use cbexlc, but things always fell apart during the link phase. I may be able to get some time on a QS22 Cell BE blade with 32GB memory in the near future; I'll try to recompile snes9x on that environment and see how things go. But again, this just shows how unrealistic it is to use cbexlc on a PS3-- a QS22 system costs over $20K!