In assembly programming, it's fairly common to want to compute something from the low bits of a register that isn't guaranteed to have the other bits zeroed. In higher level languages like C, you'd simply cast your inputs to the small size and let the compiler decide whether it needs to zero the upper bits of each input separately, or whether it can chop off the upper bits of the result after the fact.
This is especially common for x86-64 (aka AMD64), for various reasons1, some of which are present in other ISAs.
I'll use 64bit x86 for examples, but the intent is to ask about/discuss 2's complement and unsigned binary arithmetic in general, since all modern CPUs use it. (Note that C and C++ don't guarantee two's complement4, and that signed overflow is undefined behaviour.)
As an example, consider a simple function that can compile to an LEA instruction2. (In the x86-64 SysV(Linux) ABI3, the first two function args are in rdi and rsi, with the return in rax. int is a 32bit type.)
; int intfunc(int a, int b) { return a + b*4 + 3; }
intfunc:
lea eax, [edi + esi*4 + 3] ; the obvious choice, but gcc can do better
ret
gcc knows that addition, even of negative signed integers, carries from right to left only, so the upper bits of the inputs can't affect what goes into eax. Thus, it saves an instruction byte and uses lea eax, [rdi + rsi*4 + 3]
What other operations have this property of the low bits of the result not depending on the high bits of the inputs?
And why does it work?
Footnotes
1 Why this comes up frequently for x86-64: x86-64 has variable-length instructions, where an extra prefix byte changes the operand size (from 32 to 64 or 16), so saving a byte is often possible in instructions that are otherwise executed at the same speed. It also has false-dependencies (AMD/P4/Silvermont) when writing the low 8b or 16b of a register (or a stall when later reading the full register (Intel pre-IvB)): For historical reasons, only writes to 32b sub-registers zero the rest of the 64b register. Almost all arithmetic and logic can be used on on the low 8, 16, or 32bits, as well as the full 64bits, of general-purpose registers. Integer vector instructions are also rather non-orthogonal, with some operations not available for some element sizes.
Furthermore, unlike x86-32, the ABI passes function args in registers, and upper bits aren't required to be zero for narrow types.
2 LEA: Like other instructions, the default operand size of LEA is 32bit, but the default address size is 64bit. An operand-size prefix byte (0x66 or REX.W) can make the output operand size 16 or 64bit. An address-size prefix byte (0x67) can reduce the address size to 32bit (in 64bit mode) or 16bit (in 32bit mode). So in 64bit mode, lea eax, [edx+esi] takes one byte more than lea eax, [rdx+rsi].
It is possible to do lea rax, [edx+esi], but the address is still only computed with 32bits (a carry doesn't set bit 32 of rax). You get identical results with lea eax, [rdx+rsi], which is two bytes shorter. Thus, the address-size prefix is never useful with LEA, as the comments in disassembly output from Agner Fog's excellent objconv disassembler warn.
3 x86 ABI:
The caller doesn't have to zero (or sign-extend) the upper part of 64bit registers used to pass or return smaller types by value. A caller that wanted to use the return value as an array index would have to sign-extend it (with movzx rax, eax, or the special-case-for-eax instruction cdqe. (not to be confused with cdq, which sign-extends eax into edx:eax e.g. to set up for idiv.))
This means a function returning unsigned int can compute its return value in a 64bit temporary in rax, and not require a mov eax, eax to zero the upper bits of rax. This design decision works well in most cases: often the caller doesn't need any extra instructions to ignore the undefined bits in the upper half of rax.
4 C and C++
C and C++ specifically do not require two's complement binary signed integers (except for C++ std::atomic types). One's complement and sign/magnitude are also allowed, so for fully portable C, these tricks are only useful with unsigned types. Obviously for signed operations, a set sign-bit in sign/magnitude representation means the other bits are subtracted, rather than added, for example. I haven't worked through the logic for one's complement
However, bit-hacks that only work with two's complement are widespread, because in practice nobody cares about anything else. Many things that work with two's complement should also work with one's complement, since the sign bit still doesn't change the interpretation of the other bits: it just has a value of -(2N-1) (instead of 2N). Sign/magnitude representation does not have this property: the place value of every bit is positive or negative depending on the sign bit.
Also note that C compilers are allowed to assume that signed overflow never happens, because it's undefined behaviour. So e.g. compilers can and do assume (x+1) < x is always false. This makes detecting signed overflow rather inconvenient in C. Note that the difference between unsigned wraparound (carry) and signed overflow.
