Condition codes

Mark Smotherman
Last updated: April 2004

Summary: Condition codes provide architectural elegance but are troublesome for high-performance implementations.

UNDER CONSTRUCTION


Condition codes are extra bits kept by a processor that summarize the results of an operation and that affect the execution of later instructions. These bits are often collected together in a single condition or indicator register (CR/IR) or grouped with other status bits into a status register (PSW/PSR). John Hennessy, et al., in the paper "Hardware/Software Tradeoffs for Increased Performance," ASPLOS-1, Palo Alto, March 1982, pp. 2-11, identified four uses of condition codes:

  1. conditional control flow (branching)
  2. evaluation of boolean expressions
  3. overflow detection
  4. multiprecision arithmetic

They make two good arguments against including condition codes in an architecture:

  1. condition codes are a hindrance to more aggressive code scheduling by the compiler (e.g., you cannot schedule an otherwise-independent instruction between a compare instruction and a branch instruction if the otherwise independent instruction also sets the condition code); and,

  2. condition codes complicate a high-performance implementation in matching the relevant conditional-code-setting instruction with the condition-code-using instruction (as you would want to do in early branch determination).

Dick Sites in "Alpha AXP Architecture," Digital Tech. Jrnl., special Alpha issue, 1992, pp. 19-34, also rejects condition codes. His reason is similar to (b) above: multiple instruction issue is limited by any special (single-instance) or hidden (implicit) resources.

As an example of the complication that condition codes cause in high-performance implementations, consider the S/360 Model 91 (ca. 1967), which was the fastest S/360 family member and which had a deep pipeline. The Model 91 would set a tag in the youngest cc-setting instruction during decoding and broadcast a signal to reset the tags in all the older instructions still in flight. Only the tagged instruction could write to the condition codes.

The following sections examine architecture issues of control flow with and without condition codes, overflow response, and multiprecision arithmetic without an explicit carry.


Conditional control flow

The following design tree is based on Figure 6-12 in Blaauw and Brooks (1997), which depicts making decisions in instruction sequencing:

Blaauw and Brooks argue, based on orthogonality, for a visible and durable condition to decouple relational operators from branching operators:

Separating the specification of a condition from the specification of branch target improves both the understanding and the quality of the design. Such separation is achieved by making the condition explicit, and hence durable and visible. Any desired expression can produce this condition; any desired branching can be specified for this condition. (p. 354)

Note that in section 8.1.2 of D. Sima, T. Fountain, and P. Kacuk, Advanced Computer Architecture: A Design Space Approach, Addison-Wesley, 1997, the following terms are used:

See also


Some examples of implied decision style


Some examples of single instance of condition code


Some examples of separate integer and FP condition codes


Some examples of multiple condition codes

more recent IBM TDBs


Some examples of use of extra bits in result register


Some examples of use of general registers


Some examples of use of stack registers


Some examples of use of memory


Some examples of use of table


Overflow detection

... tbd ...

Without an explicit overflow bit, ...


Multiprecision arithmetic

... tbd ...

An explicit carry bit for multiprecision arithmetic dates back to at least the Harvard Mark 1 (1944). Without an explicit carry bit, Hennessy, et al., recommended that you build multiprecision words out of 31-bit units. John Mashey's comp.arch posts on multiprecision arithmetic in MIPS

... need to add current practice for multiprecision on MIPS/Alpha ...
(GMP is written in C)


[History page] [Mark's homepage] [CPSC homepage] [Clemson Univ. homepage]

mark@cs.clemson.edu