th on every PE would intuitively take twice as many cycles as running them on one code path. However, because much of the processing of any protocol is common to the processing of all protocols, a much more efficient code path can be written that performs both protocols simul- taneously. ClearSpeed claims that software that processes both protocols takes just 10 percent more cycles than software that processes a single protocol. The optimizations involved are all simple, common- sense transformations. As mentioned previously, every PE must nullify specific instructions from the underlying com- mon code that may not be applicable in its own context. This occurs through the following steps. Each PE has its own predicate stack. Instructions can be executed, such as conditionals, which push their result onto that stack. The current instruction will only affect this PE's state if all the bits in the pred- icate stack are true-in other words, all register and memory writes are gated by the OR-ing of the entire enable stack. This produces code that looks something like the following example, which is a parallel max function on 16-bit signed integers: if.gt r_src1:p2s, r_src2:p2s // 16-bit op, push results onto enable // stack. 2 cycles r_max:p2s, r_src2:p2s // 16-bit op, only on those PEs where src2 // > src1. 2 cycles otherwise // invert top bit of enable stack. 1 cycle r_max:p2s, r_src1:p2s // 16-bit op, only on those PES where src1 11 >= src2. 2 cycles endif // pop top bit from enable stack. 1 cycle The :p2s suffix on the operands indicates they are poly (parallel) 2-byte signed. The code could consist :p1u for poly 1-byte unsigned, p4s for poly 4-byte signed, or :m4u for mono, or scalar, 4-byte unsigned. Mono variables are operated on in the MTAP's thread sequence controller (TSC), which is responsible for fetching and decoding instructions. As a result, it can actually execute real branches. The sequence takes a total of eight cycles. Do not be misled by the if. gt instruction-it is not really a branch! It is simpl