On the Alpha AXP, 32-bit values are typically represented in so-called canonical form. But what happens if you use a non-canonical representation? <\/p>\n
Well, it depends on what instruction consumes the non-canonical representation. <\/p>\n
If the consuming instruction is an explicit 32-bit instruction, such as If we are willing to use a non-canonical form temporarily, we could simplify this to <\/p>\n The On the other hand, if the instruction that consumes the non-canonical 32-bit value is a 64-bit instruction, then the non-canonical value will cause trouble. <\/p>\n Consider this simple function: <\/p>\n The Windows ABI for Alpha AXP requires that all 32-bit values be passed and returned in canonical form. You are welcome to use non-canonical values inside your function, but all communication with the outside world must use canonical form for 32-bit values. <\/p>\n This function might assemble to something like this: <\/p>\n The first instruction checks whether x<\/var> is zero. If so, then it jumps directly to the If the value is not zero, then it returns to the caller. <\/p>\n There is no 32-bit version of the If the value of x<\/var> were not canonical, then the branch instruction could suffer false negatives: Even though the lower 32 bits are zero, there may be nonzero bits set in the upper half. That cause the There are a number of instructions which do not have a 32-bit version and which always operate on the full 64-bit register value. Another example: <\/p>\n This function might assemble to something like this: <\/p>\n In this version, the compiler performs a signed less-than operation and branches based on the result. The Using sign-extended values for canonical form for 32-bit values has the nice property that signed and unsigned comparisons of 32-bit values have the same results as signed and unsigned comparisons of their corresponding canonical forms. <\/p>\n If zero-extension had been used for canonical form, then unsigned comparisons would be preserved, but signed comparisons would not agree: The 32-bit signed comparison of I’m pretty sure this was not a coincidence. <\/p>\nADDL<\/code> or STL<\/code>, then the upper 32 bits are ignored, and the operation proceeds with the lower 32 bits. In that case, the non-canonical representation causes no harm. For example, consider this calculation: <\/p>\n\n ; Calculate Rc = Ra + Rb + 0x1234 (32-bit result)\n LDA Rc, 0x1234(zero) ; Rc = 0x00000000`00001234\n ADDL Rc, Rb, Rc ; Rc = Rb + 0x1234\n ADDL Rc, Ra, Rc ; Rc = Ra + Rb + 0x1234\n<\/pre>\n
\n ; Calculate Rc = Ra + Rb + 0x1234 (32-bit result)\n LDA Rc, 0x1234(Rb) ; Rc = Rb + 0x1234 (64-bit intermediate)\n ADDL Rc, Ra, Rc ; Rc = Ra + Rb + 0x1234 (32-bit result)\n<\/pre>\n
LDA<\/code> will put Rc<\/var> into non-canonical 32-bit form if Rb<\/var> is in the range 0x7FFFEDCC<\/code> to 0x7FFFFFFF<\/code> because the LDA<\/code> instruction is 64-bit only, and the result would be in the range 0x00000000`80000000<\/code> through 0x00000000`80001233<\/code>, which are non-canonical. But all is forgiven at the ADDL<\/code> instruction, since it considers only the 32-bit portion of the addends (ignoring the non-canonical part) and generates a 32-bit result in canonical form. <\/p>\n\nvoid f(int x)\n{\n if (x == 0) DoSomething();\n}\n<\/pre>\n\n BEQ a0, DoSomething ; tail call optimization\n RET zero, (ra), 1 ; return without doing anything\n<\/pre>\n
DoSomething<\/code> function, leaving the return address unchanged, so that when DoSomething<\/code> returns, it returns to the caller of f<\/code>. (This is a tail call optimization.) <\/p>\nBEQ<\/code> instruction; it always tests the full 64 bits. <\/p>\nBEQ<\/code> to report “sorry, not zero” even though the 32-bit part of a0<\/var> was zero. <\/p>\n\nvoid f(int x, int y)\n{\n if (x < y) DoSomething();\n}\n<\/pre>\n\n CMPLT a0, a1, t0 ; t0 = 1 if a0 < a1\n BNE t0, DoSomething ; tail call optimization\n RET zero, (ra), 1 ; return without doing anything\n<\/pre>\n
CMPLT<\/code> instruction always operates on the full 64-bit register value; there is no 32-bit version. Consequently, passing a non-canonical value can result in the debugger reporting strange things like “Well, even though you passed x<\/var> = 1 and y<\/var> = 2, the less-than comparison returned false because x<\/var> was passed in the non-canonical form of 0xFFFFFFFF`00000001<\/code>. <\/p>\n0x00000000<\/code> with 0xFFFFFFFF<\/code> would report that the first value is larger (0 > −1) but the 64-bit signed comparison 0x00000000`00000000<\/code> with 0x00000000`FFFFFFFF<\/code> of the corresponding zero-extended values would report that the second value is larger (0 < 4,294,967,295). <\/p>\n