11111 1 11 1111 1 1111 0100 0000 0000 0000 0000 0000 0001 1111 0100 1010 1100 0000 0000 0000 0000 0000 0000 1010 1100 --------- --------------------------------------- 1010 0000 0000 0000 0000 0000 0000 0010 1010 0000
It would not be correct to store the low order byte of the above result and claim that it is the sum of the three operands.
In general the low order byte after several 32-bit operations is not the same as would result from several true 8-bit arithmetic operations. For example, divide the above results by four (by shifting right twice). The low-order bytes are different.
These are problems that compilers face. For example, ANSI C short int variables should behave the same way on all computers. But 16-bit math does not behave the same way on all computer architectures! When C is compiled for MIPS, several extra machine operations must be inserted between each arithmetic operation when the operands are short ints. On MIPS (and some other computers) 16-bit arithmetic is much slower than 32-bit arithmetic.
Naive programmers sometimes use short ints with the expectation that their program will run faster. Depending on the hardware and the compiler, the opposite might be true!
Crytography programs often treat characters as 8-bit integers and transform them with arithmetic operations. Suppose a cryptography program is written in C for a Windows system. When compiled on a Macintosh system it runs, but produces different results! You have been given the job of making the Mac version work identically to the Windows version. What must you do?