     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Programming the Cell Broadband Engine Programmers understand that symbols are key to the entire development activity. They provide the fundamental abstraction mechanism for programmers to represent and reuse all kinds of programming elements. For example, symbols name and represent functions and data variables. A programmer writes code in certain programming language to define a symbol that can be used in other places. The definition of a symbol in a module and its use in other modules represent how the module interacts with the others. The use of the symbol effectively captures the dependency relationship of the interactions. As those interactions grow more complicated, the tool chain can help the programmer sort out the interactions by using the symbol information of the interdependent modules. However, not all the interactions can be represented by symbols. For example, the dynamic side effects of a function call can't be represented by the use of symbols or its function interfaces. When the interaction information isn't captured inside of the code module, a tool can't help the programmer manage such dependencies. A programmer needs to programmatically handle these dynamic dependencies during runtime and pay a runtime overhead. The Role of a Linker Figure 2 shows that source code is compiled into a linkable code module, which a linker subsequently combines with other linkable modules into an executable image. The executable image can now be loaded into system memory for the processor to execute.
You use the linker to combine interdependent code modules (linkables) into an executable binary image for its target processor. The entire linked image is stored in a file or a set of closely related files called executables. The linker arranges the executable image so that an operating system can load it efficiently into the system memory for execution. A linker can help you find the dependencies among the code modules. It combines the code modules together based on where a particular symbol is defined (implemented) and where the symbol is used. A symbol usually has an associated value. For a function or data object, the symbol value is usually the effective address where the function or the data object is placed in the final execution image. (Different symbol types have different kind of values. Detailed definitions can be found in the tool interface standard for the specific target architecture.) For the purposes of this article, I'll call the process of finding a symbol's definition symbol resolution and the process of connecting the use of a symbol to its matching definition symbol binding. The linker resolves and binds the symbols of the code modules ahead of time so that an application doesn't repeatedly pay the linking overhead during run time. Linking also rearranges the machine code pieces in a way that a loader can load easily into system memory. This shortens the initialization time of the program. For a CBE application, execution usually involves PPE and SPE programs interacting and running at the same time. It's also generally desirable to allow a programmer to represent the inter-architectural (PPE versus SPE) interactions symbolically in the code module so that a linker can possibly handle such dependencies. The inter-architectural linking facility will similarly improve the initialization and execution performance of the final executable image. The whole execution image of the application consists of code modules from two different instruction sets. The traditional tool chain infrastructure and Executable and Linking Format (ELF), as defined in the Tool Interface Standard, is not set up for inter-architectural linking. It assumes that the symbols and their resolution mechanism are defined and used in the same architectural space. As shown in Figure 3, early Cell programmers were forced to use two independent sets of tool chains. They used two different compilers and two different linkers, one set for the PPE executables and one set for the SPE executables. The linkables and executables for different architectures did not intermix. They had to be developed and managed separately.
Because the PPE and SPE code modules were developed separately from one another, the programmers had no way of specifying inter-architectural symbols for inter-architectural interactions. Their inter-architectural dependencies thus could not be recognized and handled by either linker. Before CESOF, a CBE programmer had to write code to handle these inter-architectural module interactions and their dependencies. This additional step not only cost performance during runtime but was also a tedious and error-prone task for the programmer.
|
|||||||||||||||||||||||||||||
Features
The Role of a Symbol
|
|
|