Gamasutra - Feature - "Programming the Cell Broadband Engine"


				\|\|\|\|

By Alex Chunghen Chow
[Author's Bio]
Gamasutra
July 21, 2006

Programming the Cell Broadband Engine

Introduction
The Role of a Symbol
Inter-Architectural
CESOF Linkable
CESOF Example
Conclusion

	Change Login/Pwd Post A Job Post A Project Post Resume Post An Event Post A Contractor Post A Product Write An Article Get In Art Gallery Submit News

	Latest Letters to the Editor: Perpetual Layoffs by Alexander Brandon [09.21.2007] Casual friendliness in MMO's by Colby Poulson [09.20.2007] Scrum deals and 'What is Scrum?' by Tom Plunket [08.29.2007] [Submit Letter] [View All...]

Features

Programming the Cell Broadband Engine

Listing 2 PPE Code That Uses the Symbol spe_hello_handle

/************************/

/* filename: ppe_main.c */

/************************/

/* the symbol "spe_foo_handle" defined in spe_hello_csf.o */

extern spe_program_handle_t spe_hello_handle;

/* an EA symbol representing an array object */

char foo[512]; /* this is the foo array that spe_hello accesses */

int main()

{

int rc, status;

speid_t spe_id;

/* load & start the spe_hello program on an SPE */

spe_id = spe_create_thread(0, &spe_hello_handle, 0, NULL, -1, 0);

/* wait for spe prog. to complete and return its status */

rc = spe_wait(spe_id, &status, 0);

printf("string from spe_hello: %s\n", foo);

return status;

}

In the call to spe_create_thread function, we use the symbol spe_hello_handle to refer to the wrapped SPE executable. Subsequently, the SPE loader uses the handle passed in for the purpose of finding the effective address of the real SPE executable image and load it into the target local store. Afterward, it loads the resolved shadow area over the TOE segment in the local store. This operation completes an SPE executable image with all the EAR entries bound to their corresponding symbol values (which are the effective addresses of the represented data objects).

After SPE loader loads the bound SPE executable image into the local store, the run-time environment then starts the execution of the SPE program.

Here are the steps used to create the final CBE application called cbe_main.

$ ppu-gcc -c ppu_main.c

$ ppu-gcc -o cbe_main ppu_main spe_hello_csf.o

Superior Linking

CESOF defines a usage convention on top of the existing ELF specification so that an SPE executable can be wrapped into a PPE linkable in a logical and standardized manner. The CESOF linkable then allows the embedded SPE executable to participate in the linking and execution with other PPE linkables.

The CBE Linux Reference Implementation ABI v1.0 contains the specification of CESOF. The reference implementation of the tool chain (the embedspu tool, SPE linker, and PPE linker) and the CESOF examples are available in the CBE SDK published by IBM. Their implementation fully supports the current CESOF specification.

This standard establishes a foundation to build a higher-level SPE compiler capable of spanning the entire effective-address range. However, we will need additional language syntax to specify the location of a data object. We'll also need additional compiler run-time support to transfer the data to and from the local store for processing.

One possible extension to the current C language for SPE programming would be the support of effective-address variables. Such support can hide all the EAR details and DMA operations from the programmers. The two C compilers in the CBE SDK don't support such higher-level effective-address abstraction yet. However, an IBM XLC prototype making use of this mechanism has been working.

The standard allows other CBE programming frameworks to represent inter-architectural connections with the EAR entries; for example, the connectors for a streaming programming framework.

Other higher-level abstractions over the whole chip, for example single-source compilers, SPE software controlled cache, or SPE code overlay, can similarly benefit from this common infrastructure.

End