Microcode is a special instruction set that is (usually) only available to the hardware. On the PPU (PowerPC Unit), small microprograms made up of microcode are stored in ROM and executed in the place of those PowerPC instructions that were too costly to implement directly in hardware or do not fit into the pipeline design very well. The size of a microprogram is measured in microwords.

The PowerPC instructions for which a microprogram is executed are often called microcoded instructions.

Microcoded instructions may be conditionally executed or unconditionally executed. Unconditionally executed microcoded instructions always execute the microprogram. Conditionally executed microcoded instructions will only execute the microprogram when the values of the register operands are exceptional in some way. Microcoded instructions are a special case of normal instructions and conditionally executed microcoded instructions are a special case of those.

Like the G5, the PPU contains microcoded instructions. Microcoded instructions are implemented in order to maintain compatibility with the PowerPC standard (a processor can only be called a PowerPC processor if it adheres to the standard [ibm.com].) When one of these instructions is decoded, the current pipeline is flushed, the microded program is then fetched from ROM and executed as a single atomic unit. The process of flushing the pipeline, fetching the microcode and executing the program takes quite a long time compared to other instructions. Additionally, because the instruction must be executed atomically in order to remain as transparent to the user as possible, any resources needed by the microcode program must be locked.


The details on which instructions are microcoded and the associated penalties are specific to each PowerPC device and are outlined in the User's Guide for the individual processor. For example, see the IBM PowerPC 970FX RISC Microprocessor User's Guide [ibm.com] paying particular attention to Section 6.3.3 Instruction Decode, Cracking, and Microcode.

The PPU User's Guide has not been released publically. So how is a programmer to know which instructions are microcoded and how to avoid them?

Read on to find out. Like many of the specific details of the processor, any good compiler needs to understand (and take advantage of) the predicted latency and throughput information on each instruction. So a programmer need look no further than the CBE GCC source code [bsc.es] for a list of microcoded instructions.

Here's an example extry from the rs6000.md file (which is used by the cell-ppu target) which flags the first instruction in the replacement ("rldicl.") as being microcoded.
Here is a partial list of the microcoded instructions explicitly flagged in the same file:


Fortunately, there is a GCC flag that will warn the programmer if a known microcoded instruction is emitted. Simply add -mwarn-microcode to your compilation flags.

This flag is defined in rs6000.h: And is processesed in rs6000.c: And is used in final.c: The other PowerPC specific compilation flags can also be found in these files. Note that -mwarn-microcode is not in the gcc help list of flags.

How does this affect code in practice? From the above list, there are three main classes of microcoded instructions to watch out for. These instructions are handy to load or store a small contiguous area of memory. However, it will always be faster to simply load each individual value into a register. GCC will not emit these instructions if the -mno-multiple flag is passed to the compiler.

List of microcoded load and store instructions, including load/store multiple. From: Cell Broadband Engine Programming Handbook [ibm.com] Many of the integer functions, when the Condition Register (CR) modify bit is set (denoted by a "dot" at the end of the instruction), are microcoded. With this bit set, fixed-point instructions will automatically set the first field (field zero) in the Condition Register with the value's compare-with-zero result. For example, if the result of the "or." instruction is greater than zero, the GT bit will be set in CR[0].

In general, this makes branching on integer expressions more expensive and an effort should be made to eliminate them.

For information on eliminating integer (fixed point) branches see:



List of CR recording microcoded instructions. From: Cell Broadband Engine Programming Handbook [ibm.com]
This is the simpliest case to find, but the hardest to eliminate: This code will emit this deceptively simple function: And the following warning (if -mwarn-microcode is enabled):
The best option for eliminating indirect shift instructions is to know the range of possible shift amounts and create an alternate branch-free expression that selects between those choices.

List of indirect shift and rotate microcoded instructions. From: Cell Broadband Engine Programming Handbook [ibm.com]
In addition to microcoded instructions there is another class of low performance instructions worth mentioning: the complex pipeline instructions. These instructions are are not microcoded (i.e. the resources already local to the execution pipeline can be used directly), however they are complex enough that special handling is required. In order for these instructions to be executed the instruction pipeline must be evacuated (i.e. flushed). Therefore the throughput of these instructions will be equal to the latency - They will be slow.

List of the non-pipelined instructions. From: Cell Broadband Engine Programming Handbook [ibm.com]

• Keep an eye out for microcoded instructions: use -mwarn-microcode in GCC.
• Don't use multiple load/store instructions: use -mno-multiple in GCC.
• Avoid CR recording integer instructions
• Avoid indirect shift and rotate instructions
• Avoid integer multiply and divide instructions

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.