Design Article

Using open-source GNU, Eclipse & Linux to develop multicore Cell apps: Part 4

Matthew Scarpino

8/31/2009 1:28 AM EDT

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.


Next:




Please sign in to post comment

Navigate to related information

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)

Feedback Form