Overview
The Condition Register (CR) is an architectural register composed of flag-like fields. Its flags participate in processor execution in two distinct ways:
- An instruction may read a CR flag, in which case the flag's current value influences the instruction's operation.
- An instruction may write a CR flag, in which case the instruction's execution alters the value stored in that flag.
The presence and meaning of CR flags in a given design (DUT) is typically discovered empirically rather than assumed, because identifying which flag influences which instruction cannot be done by simple sample comparison: different instructions rarely match in all other input features.
Detecting Read and Write Effects on CR Flags
A reference-model-based procedure is used to determine how individual flags in the condition register interact with instructions. For each generated instruction, the procedure performs the following:
- Generate an instruction.
- Collect the instruction attributes (instruction type, operands, register values).
- Store the value of the flag under test.
- Execute the instruction on a simulator (the reference model).
- Review the simulated machine state (all registers and memory) to see whether the flag has changed.
- Store the simulated machine state.
- Rollback the simulated machine state to the pre-execution state.
- Negate the value of the flag.
- Re-execute the instruction on the simulator.
- Review the simulated machine state again to see whether the flag has changed.
- Compare the two stored simulated states:
- Read detection — If the simulated states differ in anything other than the value of the flag, the flag was read by the instruction and affected its operation. Additionally, if the flag's value changed in only one of the two executions, the flag is deemed to have been read.
- Write detection — If the flag's value changed in either of the simulated executions, the instruction is deemed to write to that flag.
This procedure produces, for each instruction, a determination of which CR flags it reads and which CR flags it writes.
Effect on the Branch Conditional (bc) Instruction
The branch conditional (bc) instruction is a primary consumer of the Condition Register. Whether a given bc instruction is affected by the CR depends on its operand fields and, in some cases, on other architectural registers.
A representative sample collection (columns abbreviated) is shown below, where the final column records whether the bc instruction was affected by the CR:
| opcode | CTR | MSR.US | MSR.VMX | MSR.VSX | bi.data | bo.data | branchDisplacement | CR.Affected |
|---|---|---|---|---|---|---|---|---|
| bc | 147DB9BE3C4F54AE | 0x1 | 0x0 | 0x7 | 0x1B | 0xBAC4 | False | |
| bc | none | 0x1 | 0x0 | 0x13 | 0xC | 0x5E84 | True | |
| bc | none | 0x0 | 0x1 | 0x0 | 0x1E | 0x1C | 0x8DFC | False |
| bc | 77B3EB82A79393A1 | 0x1 | 0x0 | 0x0 | 0x5 | 0x1A | 0xD30 | False |
Classified Rules for CR-Affecting bc Instances
After a sufficient number of samples are collected, a decision-tree classifier deduces the rules that predict when bc instructions are affected by the CR. For the example data, the classifier identified only three input properties as determinants: the bo.data operand, the bi.data operand, and the contents of the CTR (in special cases).
The resulting rules for the bc instruction are:
(opcode in {bc}) & (bo.data in {0x0, 0x1, 0x8, 0x9}) & (CTR in {!0000000000000001})— always (100%), observed in 209 out of 209 attempts.(opcode in {bc}) & (bo.data in {0x4, 0x5, 0x6, 0x7, 0xC, 0xD, 0xE, 0xF})— always (100%), observed in 952 out of 952 attempts.(opcode in {bc})(no other constraint) — sometimes (47%), observed in 1193 out of 2486 attempts.
These rules capture the architectural knowledge of when bc is affected by the Condition Register without requiring manual user knowledge of the device under test.
Use in Generation
Once the rules governing CR interaction are learned, they can be applied by an instruction generator: given a requested probability, the generator selects rules that satisfy the desired probability of producing the requested CR-related behavior, allowing the construction of test sequences such as "an instruction that writes to the CR, followed by a branch that is affected by the CR."