Figure 10.1 shows the processing elements that make up the SPU. Instructions flow from the SPU Control Unit (SCN) to other functional units depending on the nature of the instruction to be processed. Data flows into the SPU’s registers through the SPU Load/Store Unit (SLS) and then travels back to the LS.

Figure 10.1. SPU functional units

There are three important differences between the SPU’s structure and the PPU’s structure, shown in Figure 6.3:

This last point is important to understand. Generally speaking, the units connected to the even pipeline perform mathematical operations, and the units on the odd pipeline handle everything else. The advantage of having two pipelines is that their corresponding units operate in parallel. For example, an SPU can read and write from memory and perform high-speed vector math at the same time.

The functions of these units are as follows:

The SCN can fetch 32 instructions at a time. Chapter 11, “SIMD Programming on the SPU,” describes vector processing with the SFP, SFX, and SFP. Chapter 12, “SPU Communication, Part 1: Direct Memory Access (DMA),” explains the SSC and the MFC.

The SPU’s functional units operate on values stored in the SPU’s register file. Unlike the PPU, which has a wide array of registers with different sizes and functions, the SPU has only two types of user registers: the general purpose registers (GPRs) and the floating-point status and control register (FPSCR). Both are 128 bits in size and are shown in Figure 10.2.

Figure 10.2. SPU user registers

The GPRs store all the information—data and instructions—used by the functional units. Altogether, they provide 16KB of storage and serve as both the SPU’s instruction cache and data cache. Each read or write to the SPU register file requires two cycles.

The FPSCR stores information related to the results of floating-point operations, such as whether an operation returned a denormalized value or attempted to divide by zero. Accessing this register is important to gain information about processing errors and special conditions. Chapter 11 discusses the FPSCR in detail.

Table 10.1 lists the scalar datatypes supported by the SPU. Like the PPU, the bits are arranged in big-endian order: the most significant bit (MSB) is on the far left and the least significant bit (LSB) is on the far right.

There are two differences between the SPU datatypes in Table 10.1 and the PPU datatypes in Table 6.1. First, there is no w_char datatype representing wide characters. Second, the last datatype in the table, qword, is available only on the SPU. qwords are required as arguments for a set of SPU functions called specific intrinsics.

As mentioned earlier, the SPU’s GPRs are 128 bits wide. When a scalar is stored in a register, it’s placed in its preferred slot. For example, if var is a halfword stored in the register, it will occupy Bytes 2 and 3 of the register. These bytes form the halfword’s preferred slot. When another operation needs to access var, it will only access these bytes of the register. Figure 10.3 shows how other scalars are stored in the SPU’s registers.

Figure 10.3. Storing scalars in vector registers

As shown, using a 16-byte register to store a byte or halfword is a terrible waste of memory. Whenever possible, combine scalars within a vector and perform operations on the vector instead.

Table 10.2 lists the different types of vectors supported by the SPU. AltiVec’s vector pixel type is gone along with the vector bool datatypes. The three new vector types are shown in boldface.

These last three vector datatypes store 64-bit scalars, and the ability to process vectors of 64-bit elements is one of the SPU’s advantages over the PPU. The vector unsigned long long and vector signed long long datatypes are straightforward to understand, but the way the SPU processes floating-point values inside vector floats and vector doubles requires further explanation.

If you’re porting an application to run on the SPU, it’s important to know how it processes floating-point values. Specifically, you need to know to what extent the SPU adheres to the common IEEE-754 standard. Figure 10.4 shows how the PPU and the SPU store floating-point values, and this format fully complies with the standard.

Figure 10.4. Single-precision and double-precision floating-point format

When it comes to processing these values in applications, however, the PPU and SPU deviate from the standard in different ways. Section 9.1, “From Scalars to Vectors,” discusses how the PPU processes floating-point vectors and its different operational modes. The SPU supports only one mode of operation, although it treats single-precision and double-precision values differently.

In processing single-precision values, the SPU differs from the standard in the following respects:

In processing double-precision values, the SPU supports NaNs and all rounding modes. It responds to denormalized values by forcing them to zero and raising a bit in the FPSCR. It also sets bits in the FPSCR in the events of overflow, underflow, inexact result, invalid operation, and NaN value propagation. These errors and the FPSCR are fully described in Chapter 11.

The SPU multipliers in the first-generation Cell only operate on 16-bit operands. For this reason, 32x32-bit integer multiplies require five instructions: three multiplications and two additions. For the sake of efficiency, use shorts as often as possible and make sure to cast constants (usually processed as ints) and small values as unsigned shorts.

Most of the elements in the C standard library and the C++ standard library are available for the SPU. Table 10.3 lists the header files in both categories.

The three starred headers in the first column can be included in SPU code, but the following functions and types are missing:

This last bullet demands further explanation. printf() can be called in SPU code, but the SPU calls on the PPU to send the text to standard output. This is called an externally assisted function call, and because of the time required to execute, printf() should be used only when timing isn’t critical.

The Cell SDK includes a number of helpful routines beyond those in the C/C++ standard libraries, and those declared in spu_intrinsics.h are foremost among them. These functions provide low-level access to the SPU instruction set. The main difference between SPU and PPU intrinsics is that SPU intrinsics start with spu_, and PPU intrinsics start with two underscores.

The SPU has no Time Base register, so there are no SPU intrinsics that perform the same function as the PPU’s __mftb(). However, the SPU has a decrementer that counts ticks within an application. This is discussed in Chapter 11.

Most of the functions in spu_intrinsics.h operate on vectors. These aren’t the same as the PPU functions in altivec.h, but they cover the same territory. Because vector processing is so important for SPU coding, Chapter 11 describes them in detail. The Cell SDK also provides the SIMD Math library and the MASSV library, which provide high-level floating-point routines for vector mathematics.

In addition to vector functions, the spu_intrinsics.h header declares functions called specific intrinsics, which map immediately to assembly language commands. Their names are similar to SPU assembly instructions, but each function starts with si_. For example, the specific intrinsic si_stqa(a, addr) stores the qword a into memory at addr, and this performs exactly the same operation as the assembly command stqa a addr. Chapter 15, “SPU Assembly Language,” discusses SPU assembly language and SPU specific intrinsics.

The Cell SDK provides many SPU libraries whose functions perform advanced mathematics and signal processing. The routines in libfft perform fast Fourier transforms (FFTs), the functions in libmc_rand generate and operate on random values, and the functions in liblarge_matrix operate on large matrices. There are also libraries for multiprecision mathematics, image manipulation, curves, and surfaces. This book doesn’t explain all the available functions, but the following chapters cover quite a few.

In addition to local reads, writes, and instruction fetches, the LS can be accessed by the PPU and other SPUs. This external access becomes a concern when a local SPU executable requires commands to execute in specific order. The SPU guarantees that local loads and stores will be executed in program order, but instruction fetches and external operations may take place at any time. This method of distributed memory access is referred to as weakly consistent.

In circumstances where the SPU’s memory access must be performed in a particular order relative to external instructions, spu_intrinsics.h declares three useful functions:

These functions, listed in order of increasing severity, effectively halt the SPU’s instruction processing until the right conditions are met. This can significantly degrade the SPU’s performance.

After the PPU selects an SPU to run the executable, it initializes the contents of the SPU’s registers and LS. For example, Chapter 7 explained that the SPU can receive three values in its main function: speid, argp, and envp. These are placed in Registers 3, 4, and 5, respectively. The CBE Linux Application Binary Interface (ABI) specifies how initialization information is placed in SPU registers, and its guidelines are listed in Table 10.4.

The call stack is the portion of LS that stores information about currently executing SPU functions. When a function is called, its return address, parameters, and local variables are stored at the memory address contained in R1. This address, called the stack pointer, is then decremented to point to the next free section of memory. When the function completes, the stack pointer returns to its earlier value.

To maximize the amount of available stack space, the PPU initializes the SPU’s stack pointer to the topmost line in the SPU’s LS (0x3FFF0). The next line, 0x3FFE0, is set aside for the return address of the next function. Figure 10.6 (left side) shows what this initial state looks like.

Figure 10.6. SPU stack before and after a function call

With each new function call, the stack grows downward to accommodate its parameters, local variables, and necessary registers. This is shown in Figure 10.6 (right side). The SP is decremented to contain the address at the bottom of the stack. The LS memory at that address, called the back chain pointer, stores the address of the previous SP.

The code in Listing 10.1 gives a clearer idea of how the stack works. The main function calls foo, bar, and baz, and displays the stack pointer (R1) after each call.

#include <stdio.h>

/* Set stack_ptr equal to Register 1 */
register volatile unsigned int *stack_ptr asm("1");

int foo(int);
int bar(int);
int baz(int);

/* foo calls bar */
int foo(int fooval) {
   printf("Foo Stack Ptr: %p
", stack_ptr);
   return bar(2*fooval);
}

/* bar calls baz */
int bar(int barval) {
   printf("Bar Stack Ptr: %p
", stack_ptr);
   return baz(2*barval);
}

/* baz returns twice the input */
int baz(int bazval) {
   printf("Baz Stack Ptr: %p
", stack_ptr);
   return 2*bazval;
}

/* main calls foo */
int main(int argc, char **argv) {
   printf("Main Stack Ptr: %p
", stack_ptr);
   return foo(2);
}

On my system, the results are as follows:

Main Stack Ptr: 0x3ff90
Foo Stack Ptr: 0x3ff60
Bar Stack Ptr: 0x3ff30
Baz Stack Ptr: 0x3ff00

The stack decrements with each function call, but the stack pointer doesn’t drop significantly. This is because foo, bar, and baz have few parameters and no local variables. But remember: The more nontrivial nested functions you have in your code, the larger your stack will be and the more likely it is that the stack will overwrite critical memory space.

After the SPU is initialized, the load process is performed in three steps:

Dynamic libraries required by an SPU executable are loaded into the LS before the executable starts. This is different from traditional dynamic loading, in which the library is loaded during execution.

Even though you can run SPU executables from the command line, you’re not accessing the SPU directly. Every call to an SPU executable is processed by the operating system running on the PPU. The PPU loads the executable onto an SPU and manages its operation in the manner described in Chapter 7.

In earlier versions of the SDK, SPU executables couldn’t be run on the command line and had to be executed with the elfspe command. Because they weren’t proper executables, they were called spulets. As of SDK 3.0, however, there’s no difference in usage between PPU and SPU executables, so no distinction will be made between them.

When the SPU starts running an executable, the SCN fills its instruction buffers (ILBs), which can each store 32 instructions. When one of the ILBs is empty, the SCN prefetches 32 more instructions to fill it. In this example, the SCN needs the 32 instructions shown in Figure 10.8.

The SPU has no way to cache instructions, so it always reads from the LS. Specifically, it sends a request to the SLS and asks for eight lines of instructions. After making the request, the SCN continues processing the instructions in its full buffer.

If there’s too much traffic between the SPU and its LS, the SCN may not get its instructions in time, and both instruction buffers will sit empty. When this happens, the SCN runs out of instructions to send into the pipeline. This condition is appropriately called runout. Runout temporarily halts your application, but you can prevent this condition by not performing load/store instructions in tight groups.

The SCN fetches instructions in two other situations. If the pipeline is purposefully emptied, or flushed, the SCN makes a new instruction request. This may occur because of spu_sync() or because the SCN incorrectly predicted a branch address. The second situation occurs when the SCN needs to fetch instructions because of an upcoming branch.

A branch instruction tells the SPU to stop fetching instructions in its current sequence and start processing instructions at a new address. There are two types of branch instructions:

Conditional branches are more important because they force the processor to predict which of two addresses will be taken. The PPU, with its Branch History Tables (BHTs), uses a combination of dynamic and static methods to make its prediction. This is discussed in Section 6.3.

The SPU has no resources for dynamic prediction, and relies on static prediction alone. This assumes that each branch is part of a loop, such as a for or while..do loop. Further, it assumes that the loop will go backward. That is, it predicts that the comparison will return true and that the branch will go to the lesser of the two possible addresses. After making this prediction, the SCN fetches instructions at the predicted address and stores them in a hint target buffer (ILBH). When the actual branch instruction is processed, these instructions are inserted into the pipeline.

At some point, the loop is going to branch forward, and the SPU’s prediction will be mistaken. When the SCN detects this, it responds by flushing its pipeline and fetching new instructions. The penalty for a branch miss is 18 cycles, so it pays to do everything you can to avoid branches in your code. If your code is branch intensive, you might be better off running the routine on the PPU.

The SPU’s decode stage is similar to the PPU’s. This stage receives two instructions from the buffer every two cycles. It analyzes both instructions and determines which of the SPU’s functions units should receive the instructions.

For example, the first instruction in Figure 10.8 is shli $126, $110, 2. The shli command stands for Shift Left Word Immediate, and the instruction shifts the bits in Register 110 left twice and stores the result in Register 126. During the decode stage, the SCN determines that this instruction should be processed by the even-pipeline SPU Fixed Point Unit (SFX). Then it issues the instruction to this unit.

The decode stage also checks for dependency errors. These occur when instructions access memory or the register file out of proper order. For example, if one instruction attempts to read from a register before another instruction writes to it, a Read-After-Write (RAW) data hazard occurs. If the decode stage detects a hazard or error, the issue stage will stall until the instructions are properly reordered.

After decoding the pair of instructions, the SCN sends one or both of them to their appropriate execution units. Whether one or both of them issues depends on which pipeline (odd or even) the instructions are sent to. If the first instruction is issued to a unit on the even pipeline and the second is issued to the odd pipeline, both instructions can be issued in one cycle. Otherwise, the first instruction will be issued in the first cycle, and the second will be issued in the next cycle.

The example code in Figure 10.8 is taken from a compiled SPU application where the compiler has ensured that the instructions will issue two at a time. The first command, shli, is processed by the SPU Fixed-Point Unit on the even pipeline, and the second, fsmbi, is processed by the SPU Load/Store Unit on the odd pipeline. Therefore, the two of them will issue at the same time. In circumstances where this is impossible, you can insert nop (even pipeline) and lnop (odd pipeline) as placeholder instructions. Chapter 15 discusses these instructions and the rest of the SPU’s instruction set.