Gamasutra - Feature - "Programming the Cell Broadband Engine"
It's free to join Gamasutra!|Have a question? Want to know who runs this site? Here you go.|Targeting the game development market with your product or service? Get info on advertising here.||For altering your contact information or changing email subscription preferences.
Registered members can log in here.Back to the home page.

Search articles, jobs, buyers guide, and more.

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

CESOF Programming Example

Let's use some code examples to illustrate how CESOF helps the Cell programmer resolve and bind interacting SPE and PPE code modules.

I'll start with an SPE program called spe_hello. The SPE programmer uses the effective address of an array named foo, defined in a PPE code module, as the target of a DMA operation. The DMA operation simply transfers a "Hello World!" string into the foo array.

The SPE compiler and linker, included in the SDK released by IBM, generate SPE programs spanning the local store. Recall that the foo symbol, which resides in the effective-address space, can't be used directly by the SPE program.

Instead, CESOF requires the SPE program to declare a special kind of variable to hold the effective-address value of foo, not the foo object itself. The CESOF specification requires that such variables be represented by symbols having the _EAR_ prefix. Such variables can be declared "unsigned long long" for 64-bit effective-address values. (Actually, an EAR entry reserves a 128-bit memory space.) The special prefix signature allows an SPE compiler or a post-processing tool to generate the EAR entries. These EAR entries reside only in the .toe section. However, their shadows in the effective-address space in the CESOF linkable will later be resolved by the PPE linker with the effective addresses of the corresponding effective-address symbols.

In the SPE code example shown in Listing 1, the _EAR_foo represents an EAR entry to be bound with the effective address of foo.

Listing 1 SPE Code Example

/*************************/
/* filename: spe_hello.c */
/*************************/
#include <cpio.h>
/* here we declare an EAR for foo's EA */
extern unsigned long long _EAR_foo;

char hello_string[] = "Hello World!";

int main(long long spuid, char** argp, char** envp)
{
/* Here we copy the string to the foo array in EA */
copy_from_ls(_EAR_foo, hello_string, sizeof(hello_string));

return 0;
}

/* this section maybe generated automatically by an SPE compiler */
/*****************************/
/* filename: spe_hello_toe.s */
/*****************************/
section .toe, "a", @progbits
.align 4
.global _EAR_foo
_EAR_foo:
.octa 0x0


These two files can be compiled and linked by the SPE compiler into an SPE executable file. Let's name it spe_hello.

$ spu-gcc -c spe_hello.c
$ spu-gas spe_hello_toe.s -o spe_hello_toe.o
$ spu-gcc -o spe_hello spe_hello.o spe_hello_toe.o


Note that, without the help of a higher-level SPE compiler, we would have to manually define an EAR entry and its associated EAR symbol (_EAR_foo) in the special .toe section by using the assembly file spe_hello_toe.s. This mechanical task can be done by a post-processing tool or, ideally, the future higher-level SPE compiler with special EAR keyword or attribute declaration.

In order for this spe_hello to participate in the linking and execution with the PPE code modules, let's embed it into a CESOF linkable.

$ embedspu spe_hello_handle spe_hello spe_hello_csf.o

We tell embedspu tool to associate the symbol--spe_hello_handle with the embedded SPE executable--spe_hello. The tool creates a CESOF linkable called spe_hello_csf.o.

In addition to the embedded SPE executable image and the shadow area, embedspu tool strips the _EAR_ prefix from the SPE EAR symbol names (in spe_hello executable) back to the matched PPE symbol names. These PPE symbol names are used to create the PPE symbol references in the shadow area. The order of the matched PPE symbol references in the shadow area must follow that of the matching EAR entries in the SPE TOE segment. The same order ensures that the EAR variables can be bound properly to the matched effective-address values.

Listing 2 shows a piece of the PPE code that uses the new symbol--spe_hello_handle.

Next: Listing 2, Conclusion

 


join | contact us | advertise | write | my profile
news | features | companies | jobs | resumes | education | product guide | projects | store



Copyright © 2005 CMP Media LLC

privacy policy
| terms of service