There are three distinct instruction sets for carrying out floating point operations on the CBE. On the PPU, scalar floating point (32 bit and 64 bit) instructions are executed on the FPU (Floating Point Unit) and vector floating point (4 x 32 bit) instructions are executed on the VXU (Vector Execution Unit). The SPU can also execute vector floating point (4 x 32 bit and 2 x 64 bit) instructions.

Most floating point instructions on both the PPU and SPU have single cycle throughputs which allows an additional floating point instruction to be issued on the following cycle. However many floating point instructions have very long latencies (number of cycles before the result can be used) and the latencies vary among the instructions.

For example: (Source: Cell Broadband Engine Programming Handbook [ibm.com]
In order to take advantage of the single cycle throughput, it is critical to fill the latency cycles with useful work. The two most significant barriers to filling the latency cycles are memory access and branching. This article will concentrate on minimizing branches. For background on why branches represent such a significant optimization barrier, see: Better Performance Through Branch Elimination

Let's look at the classic example of floating point branch elimination: fabs
Signed floating point numbers are extremely simple, the top bit is the sign bit - nothing else changes. So typically instead of doing something like this: A programmer will "optimize" out the branch by simply masking out the sign bit. Like this fairly common bit of code:
So what's wrong with that? Read on to find out... Although it may in fact work, it's illegal. Strict aliasing rules are that you can't cast (and dereference) two unrelated pointers, so the cast from (float*) to (uint32_t*) is not allowed and will result in this warning in GCC: warning: dereferencing type-punned pointer will break strict-aliasing rules
There's a good reason for this rule. Strict aliasing and the restrict keyword were introduced in C99 to allow the compiler to optimize load and store order. Disabling these optimizations will reduce performance significantly.
There are two solutions to this:

First, the C99 standard specifically states that (char*) types are related to every pointer type, so: Second, the C99 standard specifically allows (and recommends) "casting" of unreleated types through unions:
However, both options are still going to generate terrible code for the PPU. Let's have a look: The main problem is there are two load-hit-store events.

Store the original floating point value to the stack and load into fixed point register:
Store the fixed point result and load into the floating point return register:
In each case the only thing that can be done is sit around and wait for the memory to be available before it is loaded into either register set. This is extrememly slow. Not a little slower. Cripplingly slow.

Floating point instructions don't work with immediate floating point values, so those constants must be loaded seperately into FPU registers. There are two methods to accomplish this:

• The value can be built using integer instructions on the FXU, saved to memory then loaded into the FPU.
• The value can be pre-stored memory (part of the executable) and loaded directly into the FPU.

Both of these methods involve memory, so anytime you use a floating point constant you risk a cache miss, just for starters. The main disadvantages of the first method are the extra store and the potential for a load-hit-store hazard event. The value must be completely commited to the cache before it can be loaded into the FPU, which will cause the FPU load instruction to stall until the value is ready.


Let's look at a another simple function involving floating point comparisons and branches: Note the constants: Consider combining floating point comparisons: When a floating point operation requires use of the CR, it requires exclusive use. So it will effectively block the other units from using compare operations at the same time.
If you look at compiler output from this example (below), you'll see that the branches are reduced from two to one as expected. However, there is a cost involved. The CR has is moved into a fixed point register and manipulated directly. Then the final branch is actually done from a fixed point result. This isn't too bad except for the use of the microcoded "or." instruction. There's additional FPU instruction available on the PPU that will selectively move between a choice of two floating point registers based on the value of a third. fsel. Which is logically equivalent to:
Let's rewrite the function (at least pretty close, we'll talk about the differences below...) to give the compiler the best chance of using fsel: But you'll notice in the compiler output here, there is no use of fsel. So... we're going to have to call it ourselves:
We've also inverted the less-than-equal comparison to a greater-than-equal comparison. Which means that equal-to-zero will give the incorrect result. You'll have to decide on your circumstances if this is acceptable. You can also add an epsilon value to the comparison if you know you want an equal-to within a certain range.
The results from this are significantly better. No branches.
The main problem remaining is the load of the constants.
Here's the result. Wow! What a difference from the original. Fast and branch free. The IEEE754 standard is well-established as both the de facto and actual standard for floating point numbers. Although not all processors and software environments adhere strictly to the standard, it is highly-regarded and generally only the deviations from the standard are documented.

These documents provide a solid background for understanding the floating point format:

• Numerical Computation Guide [sun.com]
• Lecture Notes on the Status of IEEE Standard 754 for Binary Floating-Point Arithmetic [berkeley.edu]
• Why do we need a floating-point arithmetic standard? [berkeley.edu]
• Comparing floating point numbers [cygnus-software.com]

Mike Acton is a Senior Architect working on PS3/Cell research at Highmoon Studios (Vivendi-Universal Games) who occasionally refers to himself in the third person. Most recently, Mike was the Lead Special Effects Programmer for Darkwatch at Highmoon Studios (previously Sammy Studios) in Carlsbad, CA. Previously Mike has held Lead Programming, Playstation 2 Engine Development and Research roles with Yuke's, VBlank and BlueSky/Titus. He worked for Sony Interactive Studios in PSX development.

Mike has made regular appearances as a speaker at SCEA develpment conferences and has spoken at GDC. Mike Acton is not a framework-happy C++ programmer. He actually likes C. And assembly. In his spare time he develops hardware on FPGAs in VHDL.

He prefers vi.

Also check out the non Cell BE articles by Mike Acton.