{"id":99435,"date":"2018-08-07T07:00:00","date_gmt":"2018-08-07T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=99435"},"modified":"2019-03-13T00:38:05","modified_gmt":"2019-03-13T07:38:05","slug":"20180807-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20180807-00\/?p=99435","title":{"rendered":"The PowerPC 600 series, part 2: Condition registers and the integer exception register"},"content":{"rendered":"

The integer exception register xer<\/var> contains a bunch of stuff, but the ones that are relevant to us are <\/p>\n\n\n\n\n\n
Bit<\/th>\nName<\/th>\n<\/tr>\n
0<\/td>\nSummary overflow<\/td>\n<\/tr>\n
1<\/td>\nOverflow<\/td>\n<\/tr>\n
2<\/td>\nCarry<\/td>\n<\/tr>\n<\/table>\n

Some instructions update the overflow and summary overflow bits in the xer<\/var> register. When those instructions are executed, the overflow bit is updated to represent whether the operation resulted in a signed overflow. The summary overflow bit accumulates all the overflow bits since it was last explicitly reset. This lets you perform a series of arithmetic operations and then test a single bit at the end to see if an overflow occurred anywhere along the way. <\/p>\n

Some instructions consume and\/or target the carry bit in xer<\/var>. We’ll discuss how carry works when we get to integer arithmetic. <\/p>\n

Each of the cr#<\/var> condition registers consists of four bits, numbered from most signficant to least significant. <\/p>\n\n\n\n\n\n\n
Bit<\/th>\nName<\/th>\nMnemonic<\/th>\n<\/tr>\n
0<\/td>\nLess than<\/td>\nlt<\/var><\/td>\n<\/tr>\n
1<\/td>\nGreater than<\/td>\ngt<\/var><\/td>\n<\/tr>\n
2<\/td>\nEqual to<\/td>\neq<\/var><\/td>\n<\/tr>\n
3<\/td>\nSummary overflow<\/td>\nso<\/var><\/td>\n<\/tr>\n<\/table>\n

For convenience, the assembler predefines the constants lt<\/var>, gt<\/var>, eq<\/var>, and so<\/var> to represent their respective bit numbers. <\/p>\n

The cmp<\/code> family of instructions compare two values and write the result to a condition register. <\/p>\n

\n    cmpw    crd, ra, rb     ; crd = compare ( int32_t)ra with ( int32_t)rb\n    cmpwi   crd, ra, imm16  ; crd = compare ( int32_t)ra with ( int16_t)imm16\n    cmplw   crd, ra, rb     ; crd = compare (uint32_t)ra with (uint32_t)rb\n    cmplwi  crd, ra, imm16  ; crd = compare (uint32_t)ra with (uint16_t)imm16\n<\/pre>\n
You can compare two registers, or you can compare a register with an immediate, and you can choose whether the comparison is signed or unsigned. (Recall that the l<\/code> stands for logical<\/i>.) For example: <\/p>\n
\n    cmpw    cr3, r0, r1     ; cr3 = compare r0 with r1 as signed values\n<\/pre>\n
 The lt<\/var>, gt<\/var>, and eq<\/var> bits are set according to the result of the comparison, and the so<\/var> bit receives a copy of the current summary overflow bit in xer<\/var>. <\/p>\n
If you do not specify a destination comparison register, it defaults to cr0<\/var>: <\/p>\n
\n    cmpw    ra, rb          ; cr0 = compare ( int32_t)ra with ( int32_t)rb\n    cmpwi   ra, imm16       ; cr0 = compare ( int32_t)ra with ( int16_t)imm16\n    cmplw   ra, rb          ; cr0 = compare (uint32_t)ra with (uint32_t)rb\n    cmplwi  ra, imm16       ; cr0 = compare (uint32_t)ra with (uint16_t)imm16\n<\/pre>\n
As we’ll see later, some arithmetic instructions implicitly update cr0<\/var> by comparing the computed result against zero. (Similarly, some floating point operations implicitly update cr1<\/var>.) When performed as part of an arithmetic instruction, the comparison is always performed as a signed comparison, even if the instruction’s underlying operation was unsigned. <\/p>\n
If you combine an update of cr0<\/var> with an arithmetic operation, the so<\/var> bit is a copy of the summary overflow bit in the xer<\/var> register at the end of the instruction. That means that if an arithmetic operation requests both cr0<\/var> and xer<\/var> to be updated, the xer<\/var> register is updated first, and then the summary overflow bit from xer<\/var> is copied to the so<\/var> bit in cr0<\/var>. That means that the so<\/var> bit in cr0<\/var> captures whether a signed overflow occurred in any overflow-detecting operation up to and including the current one. <\/p>\n
The Microsoft compiler tends to prefer to target cr6<\/var> and cr7<\/var> in its comparison instructions. It doesn’t make much difference to the processor, but I suspect the compiler tries to avoid cr0<\/var>  so that it doesn’t conflict with the use of cr0<\/var> by the arithmetic instructions. <\/p>\n
\n    mcrxr  crd              ; crd = first four bits of xer\n<\/pre>\n
The “move to condition register from xer<\/var>” instruction copies the summary overflow, overflow, and carry bits from the xer<\/var> register to the specified condition register, and then it clears the bits from xer<\/var>. <\/p>\n
No, I don’t know why they left the “e” out of the opcode. <\/p>\n
This is how you reset the summary overflow.¹ <\/p>\n
\n    mtxer  ra               ; xer = ra\n    mfxer  rd               ; rd = xer\n<\/pre>\n
These instructions² move to\/from the xer<\/var> register. They are another way to clear the xer<\/var> register, or to set it to a particular initial state. <\/p>\n
There are a good number of bitwise operations that combine two condition register bits and store the result into a third condition register bit. These let you build boolean expressions out of condition registers. <\/p>\n
\n    crand   bd, ba, bb  ; cr[bd] =   cr[ba] &  cr[bb]\n    cror    bd, ba, bb  ; cr[bd] =   cr[ba] |  cr[bb]\n    crxor   bd, ba, bb  ; cr[bd] =   cr[ba] ^  cr[bb]\n    crnand  bd, ba, bb  ; cr[bd] = !(cr[ba] &  cr[bb])\n    crnor   bd, ba, bb  ; cr[bd] = !(cr[ba] |  cr[bb])\n    creqv   bd, ba, bb  ; cr[bd] = !(cr[ba] ^  cr[bb])\n    crandc  bd, ba, bb  ; cr[bd] =   cr[ba] & !cr[bb] \"and complement\"\n    crorc   bd, ba, bb  ; cr[bd] =   cr[ba] | !cr[bb] \"or complement\"\n<\/pre>\n
Remember that the PowerPC numbers bits from most significant to least significant, so bit zero is the high-order bit. <\/p>\n
To save you from having to memorize all the bit numbers, the assembler lets you write cr0<\/var> to mean 0, cr1<\/var> to mean 1, and so through cr7<\/var> which means 7. Combined with the constants for the four bits in the condition register, this lets you write <\/p>\n
\n    crand   4*cr3+eq, 4*cr2+lt, 4*cr6+gt ; cr3[eq] = cr2[lt] & cr6[gt]\n<\/pre>\n
instead of the instruction only a processor’s mother could love: <\/p>\n
\n    crand   14, 8, 25                    ; cr3[eq] = cr2[lt] & cr6[gt]\n<\/pre>\n
There are also special instruction for transferring between cr<\/var> and a general-purpose register. <\/p>\n
\n    mfcr    rt           ; rt = cr\n    mtcrf   mask, ra     ; cr = ra (selected by mask)\n<\/pre>\n
The mask is an 8-bit immediate. If a bit is set, then the corresponding cr#<\/var> is copied from the corresponding bits of ra<\/var>. For example, 128 means “Copy the top four bits of ra<\/var> into cr0<\/var>, and leave all the other condition registers alone.” Recall that the PowerPC counts bits from most significant to least significant, so cr0<\/var> is stored in the highest-order four bits. <\/p>\n
The assembler provides synthetic instructions for various special cases of the above operations: <\/p>\n
\n    creqv   bd, bd, bd  ; crset   bd          ; cr[bd]  = 1\n    crxor   bd, bd, bd  ; crclr   bd          ; cr[bd]  = 0\n    cror    bd, ba, ba  ; crmove  bd, ba      ; cr[bd]  = cr[ba]\n    crnor   bd, ba, ba  ; crnot   bd, ba      ; cr[bd]  = !cr[ba]\n    mtcr    ra          ; mtcrf   255, ra     ; cr = ra\n<\/pre>\n
Here’s an example of how these boolean operations could be used: <\/p>\n
\n    cmpw    cr2, r4, r5 ; compare r4 with r5, put result in cr2\n    cmpw    cr3, r6, r7 ; compare r6 with r7, put result in cr3\n    crandc  4*cr0+eq, 4*cr2+gt, 4*cr4+eq ; cr0[eq] = cr2[gt] & !cr4[eq]\n    beq     destination ; jump if r4 > r5 && r6 != r7\n<\/pre>\n
We perform two comparison operations and put the results into cr2<\/var> and cr3<\/var>. We then perform a boolean “and not” operation that calculates <\/p>\n
\n    cr0[eq] = (r4 > r5) & !(r6 == r7)\n            = (r4 > r5) & (r6 != r7)\n<\/pre>\n
The result is placed into the eq<\/var> position of cr0<\/var>, which makes it a perfect place to be the branch condition of the beq<\/code> instruction. <\/p>\n
The traditional way of doing this on processors that don’t have these fancy condition register operations is to perform a test and a conditional branch, then another test and another conditional branch. Combining the results of the test and performing a single branch means that the entire sequence consumes only one slot in the branch predictor. This leaves more slots free to predict other branches, and the single slot this sequence does consume can predict the final result, which might be easier to predict than the individual pieces. (For example, the test might be validating that a parameter is one of two valid values. The parameter is almost always valid, even though one might not be able to predict which of the two valid values it is at any particular time.) <\/p>\n
Fabian Giesen notes that in practice, you don’t get to perform this optimization as often as you’d like<\/a> because of short-circuiting rules in many programming languages. Under those rules, this optimization works only if the second term can be evaluated without any risk of taking any exceptions (or if the language permits you to take an exception anyway, say, because any exception would be the result of undefined behavior). <\/p>\n
I have yet to see the Microsoft C compiler for PowerPC perform this optimization. It just does things the conventional way. But that may just be because I haven’t encountered a situation where the optimization is even possible. (Also, because I’m studying code from Windows NT 3.51, and compiler technology was not as advanced back then.) <\/p>\n
Okay, next time<\/a> we’ll start doing some arithmetic. <\/p>\n
¹ You might have noticed that there are only three interesting bits in xer<\/var> but room for four bits in a condition register. The last bit is undefined. Usually, you don’t care much about the bits that got transferred; the main purpose of the instruction is its side effect of clearing the summary overflow. <\/p>\n
² These instructions are actually special cases of the mtspr<\/code> and mfspr<\/code> instructions which move to\/from a special register. The xer<\/var> register is formally register spr1<\/var>, so the mtxer<\/code> and mfxer<\/code> instructions are technically synthetic instructions. <\/p>\n
\n    mtspr  1, ra            ; spr1 = ra\n    mfspr  1, rd            ; rd = spr1\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
Keeping track of things that happened.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[2],"class_list":["post-99435","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-history"],"acf":[],"blog_post_summary":"
Keeping track of things that happened.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/99435","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=99435"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/99435\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=99435"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=99435"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=99435"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}