Some applications, mostly in the realm of scientific computing (MATLAB, Mathematica, MAPLE, etc.) and simulations, require 64-bit integers because they work with numbers outside the dynamic range of 32-bit integers. When the result of a calculation exceeds the range of possible integer values, you get a situation called either overflow (i.e. the result was greater than the highest positive integer) or underflow (i.e. the result was less than the largest negative integer). When this happens, the number you get in the register isn't the right answer. There's a bit in the x86's processor status word (see this page for a bit more on the PSW) that allows you to check to see if an integer has just exceeded the processor's dynamic range, so you know that the result is bogus. Such situations are very, very rare in integer applications. As an engineering student I never ran into this problem, although I did run into the somewhat related problem of floating-point round-off error a few times.
Programmers who run into integer overflow or underflow problems on a 32-bit platform do have the option of using a 64-bit integer construct provided by a higher level language like C. In such cases, the compiler uses two registers per integer, one for each half of the integer, to do 64-bit calculations in 32-bit hardware. This has obvious performance drawbacks, making it less desirable than a true 64-bit integer implementation.
Finally, there is another application domain for which 64-bit integers can offer real benefits: cryptography. Most popular encryption schemes rely on the multiplication and factoring of very large integers, and the larger the integers the more secure the encryption. As we'll discuss in the final section, AMD is hoping that the growing demand for tighter security and more encryption in the mainstream business and consumer computing markets will make a cheap, 64-bit, x86-compatible processor attractive.
