Cell software development on the IBM Full-System Simulator described in
Part 3 in
this series generally takes six steps, some of which are optional:
1. Configure simulation parameters (PPU mode, SPU mode) and identify
data collection procedures (triggers, emitters) using the command
window.
2. Build a Cell executable on the host system using the SDK's
cross-development tools.
3. Transfer the executable and support files from the host system to
the simulated Cell using the callthru source command in the console
window.
4. Run files on the simulated Cell by entering commands in the
console window.
5. Transfer output files from the simulated Cell to the host system
using the callthru sink command in the console window.
6. Use the command window to access data generated during the
simulation.
Data collection methods, including triggers and emitters, will be
presented shortly. For now, let's simulate a simple application: the
Sieve of Eratosthenes executable from the previous section.
Building the Example Application
If the host processor isn't a 64-bit PowerPC, the Cell SDK installer
installs packages for cross-development.The tools in these packages run
on the host processor but compile code for the Cell. They have the same
names (ppu-gcc, spu-gcc) as those described in Part 2 in this
series, but the compiled executables can't run directly on the host
processor.
(Note: At the time of this writing, the directory
containing the cross-development tools isn't added to the PATH
environment variable. To ensure that the makefiles work properly, add
/opt/cell/toolchain/bin to the PATH variable.)
The code for this example can be found in the Chapter4/sieve
directory.To build the application, change to this directory
and enter make.This invokes the build commands in Makefile, which use
the host's cross-development tools to generate the spu_sieve
executable.
Transferring the Application to the Simulated Cell
The host processor can't run spu_sieve because it was compiled for the
Cell.To transfer the executable to the simulated Cell, you need the
callthru command. This command, entered in the console window,
transfers files between the host and the simulated device. It can be
used in two ways:
1) callthru source
$(HOST_DIR)/file_name > $(CELL_DIR)/file_name
2) callthru sink
$(HOST_DIR)/file_name < $(CELL_DIR)/file_name
where HOST_DIR is a directory on the host system and CELL_DIR is a
directory on the simulated Cell.The first command, callthru source,
transfers file_name from the host to the simulated device and the
second, callthru sink, transfers file_name from the simulated device to
the host.
To reduce the size of the pathname on the host, it's common to move
files to the host's /tmp directory before transferring them to the
Cell. Change to the Chapter4/sieve directory and enter
cp
spu_sieve /tmp
Then transfer the executable to the simulated device by entering the
following command in the console window:
callthru
source /tmp/spu_sieve > spu_sieve
The spu_sieve file will be placed in the current directory on the
simulated Cell. It's a good idea to run ls to make sure the transfer
completed properly.
Running the Application
If you attempt to run the executable immediately, you'll receive a
permission error. Make the file executable with
chmod
+x spu_sieve
and run it by calling ./spu_sieve in the console window.The console
will present a list of the prime numbers less than 250. Optionally, you
can transfer spu_sieve back to /tmp on the host by entering the
following:
callthru
sink /tmp/spu_sieve < spu_sieve
callthru is a vital command in the console window, so it's important
to have a clear understanding of how it's used.