If the only difference between 32bit and 64bit CPUs is their register size then why must 32 bit programs be rewritten for a 64 bit platform?

Question

What is the actual difference in terms of source code when writing a 64 bit program? For example is only the assembly different? It's not like there's a 64 bit version of C++. If it's something as simple as an option on the compiler than how come more programs aren't natively 64 bit? If the only difference of 32 bit vs 64 bit CPU is the register size, I can't see how that affects a program (aside from being able to address more memory).

Answer 1

Typical pitfalls for 32bit/64bit porting are:

1. The implicit assumption by the programmer that sizeof(void*) == 4 * sizeof(char).
   If you're making this assumption and e.g. allocate arrays that way ("I need 20 pointers so I allocate 80 bytes"), your code breaks on 64bit because it'll cause buffer overruns.

2. The "kitten-killer" (re @SK-logic), int x = (int)&something; (and the reverse, void* ptr = (void*)some_int). Again an assumption of sizeof(int) == sizeof(void*). This doesn't cause overflows but looses data - the higher 32bit of the pointer, namely.
   
   Both of these issues are of a class called type aliasing (assuming identity / interchangability / equivalence on a binary representation level between two types), and such assumptions are common; like on UN*X, assuming time_t, size_t, off_t being int, or on Windows, HANDLE, void* and long being interchangeable, etc...

3. Assumptions about data structure / stack space usage (See 5. below as well). In C/C++ code, local variables are allocated on the stack, and the space used there is different between 32bit and 64bit mode due to the point below, and due to the different rules for passing arguments (32bit x86 usually on the stack, 64bit x86 in part in registers). Code that just about gets away with the default stacksize on 32bit might cause stack overflow crashes on 64bit.
   This is relatively easy to spot as a cause of the crash but depending on the configurability of the application possibly hard to fix.

4. Timing differences between 32bit and 64bit code (due to different code sizes / cache footprints, or different memory access characteristics / patterns, or different calling conventions ) might break "calibrations". Say, for (int i = 0; i < 1000000; ++i) sleep(0); is likely going to have different timings for 32bit and 64bit ...

5. Finally, the ABI (Application Binary Interface). There's usually bigger differences between 64bit and 32bit environments than the size of pointers...
   Currently, two main "branches" of 64bit environments exist, IL32P64 (what Win64 uses - int and long are int32_t, only uintptr_t/void* is uint64_t, talking in terms of the sized integers from <stdint.h>) and LP64 (what UN*X uses - int is int32_t, long is int64_t and uintptr_t/void* is uint64_t), but there's the "subdivisions" of different alignment rules as well - some environments assume long, float or double align at their respective sizes, while others assume they align at multiples of four bytes. In 32bit Linux, they align all at four bytes, while in 64bit Linux, float aligns at four, long and double at eight-byte multiples.
   The consequence of these rules is that in many cases, bith sizeof(struct { ...}) and the offset of structure/class members are different between 32bit and 64bit environments even if the data type declaration is completely identical.
   Beyond impacting array/vector allocations, these issues also affect data in/output e.g. through files - if a 32bit app writes e.g. struct { char a; int b; char c, long d; double e } to a file that the same app recompiled for 64bit reads in, the result will not be quite what's hoped for.
   The examples just given are only about language primitives (char, int, long etc.) but of course affect all sorts of platform-dependent / runtime library data types, whether size_t, off_t, time_t, HANDLE, essentially any nontrivial struct/union/class ... - so the space for error here is large,

And then there's the lower-level differences, which come into play e.g. for hand-optimized assembly (SSE/SSE2/...); 32bit and 64bit have different (numbers of) registers, different argument passing rules; all of this affects strongly how such optimizations perform and it's very likely that e.g. SSE2 code which gives best performance in 32bit mode will need to be rewritten / needs to be enhanced to give best performance 64bit mode.

There's also code design constraints which are very different for 32bit and 64bit, particularly around memory allocation / management; an application that's been carefully coded to "maximize the hell out of the mem it can get in 32bit" will have complex logic on how / when to allocate/free memory, memory-mapped file usage, internal caching, etc - much of which will be detrimental in 64bit where you could "simply" take advantage of the huge available address space. Such an app might recompile for 64bit just fine, but perform worse there than some "ancient simple deprecated version" which didn't have all the maximize-32bit peephole optimizations.

So, ultimately, it's also about enhancements / gains, and that's where more work, partly in programming, partly in design/requirements comes in. Even if your app cleanly recompiles both on 32bit and 64bit environments and is verified on both, is it actually benefitting from 64bit ? Are there changes that can/should be done to the code logic to make it do more / run faster in 64bit ? Can you do those changes without breaking 32bit backward compatibility ? Without negative impacts on the 32bit target ? Where will the enhancements be, and how much can you gain ?
For a large commercial project, answers to these questions are often important markers on the roadmap because your starting point is some existing "money maker"...

Answer 2

Not all programs have to be re-written to work on 64-bit platforms. Often, programs are rewritten so as to take advantage of the greater freedoms available on some 64-bit OS, such as larger address space, but that doesn't mean they have to be rewritten to work.

Some programs might have to be recompiled, leaving source code unchanged. Some programming environments that use an intermediate representation and just-in-time compilation allow the same binaries to run unchanged on 32- or 64-bit OS.

Where native programs need to be rewritten, it is normally due to assumptions about pointer size, as other answers have stated. Some people might call those assumptions bugs.

Answer 3

They have different memory alignment issues, plus many novice programmers assume a 32-bit everything (pointer size, file offset, timestamp size, etc.).

Answer 4

For a correctly-written program in a compiled language, all that needs to be done is recompiling it. The only programs that need to be "rewritten" (or even modified) are ones that were poorly written to begin with and which are making lots of bogus assumptions and probably invoking undefined behavior like wild.

For languages that aren't compiled to machine code but interpreted or run in some semi-interpreted/bytecode/JIT form, it's actually rather difficult to make a program that breaks when migrated from a 32-bit machine to a 64-bit one. Probably the most likely way it could "break" is just by using more memory and possibly running out.