使用的例子：在 Cell BE 处理器上编写高性能的应用程序
网址：http://www.ibm.com/developerworks/cn/linux/pa-linuxps3-1/
注意如果想直接用spu-gcc之类的命令，要先在/etc/profile里设置好PATH。
一.编译spu
1.spu-gcc spe_distance.c -o spe_distance
In file included from spe_distance.c:2:
/opt/cell/toolchain/lib/gcc/spu/4.1.1/include/spu_mfcio.h:31:20: error: stdint.h: No such file or directory
2.spu-gcc -I/opt/cell/sysroot/usr/include spe_distance.c -o spe_distance
/opt/cell/toolchain/lib/gcc/spu/4.1.1/../../../../spu/bin/ld: crt1.o: No such file: No such file or directory
3.find /usr/lib -name crt1.o
/usr/lib/crt1.o
/usr/lib/cell/sysroot/usr/spu/lib/crt1.o
4.
/opt/cell/toolchain/lib/gcc/spu/4.1.1/../../../../spu/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
原因：无法连接到c库，可能路径设置不正确，需要-L正确的路径。lc中的c实际上是libc的简写
最后发现实际上在/usr/lib/cell/sysroot/usr/spu/lib中含有libc.a,把它加入-L路径试试。
spu-gcc -I/opt/cell/sysroot/usr/include -L/usr/lib/cell/sysroot/usr/spu/lib spe_distance.c -o spe_distance
果然可以了，编译过程产生的这些错误，基本上都是由于lib或者include的路径设置不正确导致的。比如上面的
-I/opt/cell/sysroot/usr/include -L/usr/lib/cell/sysroot/usr/spu/lib 就是为了编译器可以找到正确的路径。
二.嵌入ppu
注意：我安装的embedspu calculate_distance_handle spe_distance spe_distance_csf.o
要改成ppu-embedspu calculate_distance_handle spe_distance spe_distance_csf.o
在进行这一步时，居然又出错了，如下：
Assembler messages:
Fatal error: invalid listing option `6′
想起在初始安装的时候，toolchain部分曾经在alien阶段，出过错，于是又全部安装了一下。这才好了。
三.编译ppu部分
ppe_distance.c:2:20: error: libspe.h: No such file or directory
ppe_distance.c:6: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘calculate_distance_handle’
原因如下：http://www.ibm.com/developerworks/forums/thread.jspa?threadID=192737
The example you are trying to compile uses libspe. SDK 3.0 uses libspe2. They aren’t the same, so there are a number of changes you would need to make to the code to get it to work with libspe2. There was a thread yesterday that showed some of the differences: http://www-128.ibm.com/developerworks/forums/thread.jspa?threadID=195262&tstart=0
使用另一个例子：Cell 编程登堂入室
网址：http://www.ibm.com/developerworks/cn/linux/l-cn-cellprogramming/index.html这个上面的例子，就可以正常运行了。
四.在模拟器运行
1.注意要设置path路径，同时要安装libBLT24.so
export PATH=/opt/ibm/systemsim-cell/bin:$PATH
systemsim -g
点击图2界面上“Mode”，选择“Fast Mode”，然后点击“Go”按钮，得到如下Linux操作系统启动后的界面（图3），因为是启动了一个独立的 Linux 操作系统，所以有些慢：
2.另外在fedora9里运行时，sim只显示了两个空白窗口，原因：
Regarding the two empty windows, I think this is caused by a bug in the Tk package included in the base Fedora 9 distro. Try updating your Tcl and Tk packages to the latest … I believe that will fix the problem.
Mike Kistler
3.sim运行时出现如下问题：http://www.ibm.com/developerworks/forums/thread.jspa?threadID=230667
t looks that on SDK 3.1 and Fedora Core 9 run of the simulator brings
"::tcl::Bgerror {out of stack space (infinite loop?)} {-code 1 -level 0 -errorcode NONE -errorinfo {out of stack space (infinite loop?)
while execu…"
looping
As it looks – simulator just stock and malfunctioning.
解决方案：http://www.ibm.com/developerworks/forums/thread.jspa?threadID=230317
首先我安装了cell sdk的ext部分，然后将tcl从8.3更新到8.5.仍然有问题，有人提出：
workaround that works : ulimit -s unlimited before start of systemsim -g
4.虽然可以出来模拟起，但是./test之后，并没有显示结果。于是测试了一个最简单的helloword,发现这个还是可以输出的。
而且如果不用systemsim -g,而是采用systemsim 进入后，选择mysim go,则没有出现上面的tcl错误，但是速度很慢。
5.还有一个问题，systemsim -g启动的时候，出现如下提示：
vmlinux_get_struct_info got errors: couldn’t execute "/opt/ibm/systemsim-cell/bin/../bin/parse_dwarf.pl": no such file or directory.
解决方法：
The parse_dwarf.pl file was mistakenly left out of the current rpm package for the simulator. This will be fixed soon. However, the simulator should function fine without it, except for the message you observed.
Mike
6.注意：
ulimit -s unlimited的确起到了作用，sim启动后，没有异常了当进入cell的系统后而且，前面的界面也可以有相应了。
将可执行文件copy到cell模拟器中运行，命令如下：
callthru source /home/duanple/test/test>test
chmod +x test
./test
7.如果选择fast mode执行，则没有输出，当换成cycle mode出现如下输出：
/lib/libc.so.6 unsupported version of 256 verdef record
/lib/libpthread.so.0 unsupported version of 21856 verdef record
/lib/libpthread.so.0 unsupported version of 21856 verdef record
/lib/libgcc_s.so.1 unsupported version of 8 verdef record
/lib/ld.so.1 unsupported version of 19654 verdef record