     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Programming the Cell Broadband Engine It turns out that the majority of Cell's inter-architectural module interactions can be mapped to different effective addresses. The effective addresses can be logically represented by symbols in the effective-address space (on the PPE side). CESOF is a usage convention of the current ELF. It allows you to associate these PPE symbols with the corresponding SPE modules. The new convention thus allows the SPE modules to "participate" in a meaningful way to the module interaction in the PPE linking and execution process. So far, I have identified two types of commonly seen inter-architectural program interactions that could be logically represented by PPE symbols. The representation allows the PPE linker and runtime environment to effectively resolve and bind such dependencies on behalf of the programmer. I indicated these interactions using the blue lines in Figure 3. Note that there are other kinds of inter-architectural interactions, like mailbox access and interrupts, that can't be mapped to effective addresses or symbol representations reasonably well. You still have to handle those interactions manually. PPE Program Accessing SPE Programs The first type of interaction relates to the role of a PPE program in a CBE application. Due to the generic nature of the PPE core, a PPE program usually acts as a controller. It starts and stops other PPE tasks as well as the interacting SPE programs. You can see in Figure 3 that before an SPE program can be loaded into the SPE local store for execution, the SPE executable image must first be mapped (either by the operating system at run time or by the PPE program itself) to a global effective-address memory. The mapped address can then be made available to the controlling PPE program. Through an SPE loader, the SPE executable image is then transferred (via DMA) from the effective-address memory to the SPE's local store for execution. For any SPE programs needed by a CBE application, their mapped effective addresses must eventually be given to the SPE loader. You can logically assign a PPE symbol to represent this SPE executable image, and the symbol value will be its mapped effective address. SPE Program Accessing PPE Symbols The second type of interaction is when an SPE program needs the effective address of a certain data object residing in the effective-address space. In most cases, the global address is used as the source or target of a DMA operation. In conventional single-architecture programming, you can obtain the effective address directly through the symbol value of a statically defined data object. The SPE programming environment, however, doesn't have any such symbol representation in the shared symbol space. You must use other runtime means, such as an explicit DMA operation, to pass an effective address to an SPE program. Setting up this type of interaction can be tedious and error-prone for a programmer without the help of a linker. It also costs run-time overhead during program initialization. For statically defined EA (effective-address) data objects, CESOF introduces a new type of SPE variable to hold effective addresses in the SPE program, as shown in Figure 4. These variables are called an effective-address reference (EAR). Each EAR variable keeps one resolved effective address of a PPE symbol. (Note that the EAR variable is not the EA data object itself.) CESOF logically assigns the EAR variable an SPE symbol "mangled" from the associated PPE symbol name. CESOF prefixes the _EAR_ string to the original PPE symbol.
I'll show later how providing such an association enables a linker or similar tool to use the symbol information to bind the EAR variables to their corresponding effective-address values and thus effectively pass to the SPE program these effective addresses. On the other hand, a PPE program may also need to access the locally stored data objects represented by the SPE symbols defined in the SPE code module. Because the resolved value of an SPE symbol doesn't change in different context when the SPE executable is used by different PPE programs, the resolved symbol value can be extracted directly from the symbol information of the SPE executable. The extracted values can be reused directly by the PPE linker (per linker script). There's still some discussion over whether the CESOF specification should be extended to cover this.
|
|||||||||||||||||||||||||||||
Features
Inter-Architectural Program Interactions
|
|
|