关于整数内存分配

Question

If the memory allocated to an integer has a limit (say 2 bytes in C or 4 bytes or 8 bytes) in any language. How does it matter to compile the code on 32-bit or 64-bit machine using 32-bit or 64-bit compiler. Please forgive me if it is really trivial question. But please leave an answer.

Answer 1

If you are using fixed-size integer types (like int8_t or int16_t ) then whether you target a 32- or 64-bit platform doesn't matter much.

One of the things that does matter is the size of pointers. All pointers are 32 bits when targeting a 32-bit architecture, and 64 bits when targeting a 64-bit architecture.

It used to be rather common to store pointer values in an int , though this practice has become very discouraged for portability reasons, and the 32/64-bit case is a great example. If you store a pointer in an int , then your code will invoke undefined behavior on 64-bit architectures, as you truncated a pointer. When you would go to extract the pointer, you'd dereference it likely crash, or (worse) proceed with invalid data.

Answer 2

There are several reasons why you have to compile different executables between 32-bit and 64-bit machines - the size of an int might not be a factor, or it might, since the C standard only defines minimums and relative sizes - there is no maximum size of an int so far as I know (provided it is not longer than a long).

The size of a pointer is a major difference. The compiler and linker produce a different layout of executable file between 32 and 64 bit process address spaces. The runtime libraries are different, and dynamically linked libaries ( shared objects on UNIX) have to share the same size pointers, otherwise they cannot interact with the rest of the process.

Why use 64-bit? What is the advantage of 64-bit over 32-bit? The main advantage is the maximum size of a pointer, and hence process-address space. On 32-bit this is 4GB, on 64-bit it is 16EB (about 16,000 terabytes).

Answer 3

If you have a look at this page , you can see that the basic types in C have certain guaranteed minimum sizes. So, you will not find a compliant C implementation where int is 2 bits, it has to be at least 16.

Differences between platforms makes porting software into the interesting challenge it often is.

If you have code that assumes things about basic data types that are not guaranteed to be true (for instance, code that does something like this: int x = 0xfeedf00d; ), then that code will not be portable. It will break, in various often hard to predict ways, when compiled on a platform that doesn't match the assumptions. For instance, on a platform where int is 16 bits, the above code would leave x set to some different value from what the programmer intended.

Answer 4

For the most part the word size affects performance and stack usage. It's fastest to work with whatever the word size is for a given architecture. If you define two 32 bit integers, one right after the other, on a 64 bit machine, one will be on a word boundary and the other won't. It takes less processing to get the one on the word boundary into a register than the one that's not on a word boundary. On the other hand, if you have a 64 bit integer defined on a 32 bit machine, it will take two fetches to get the two words and some funky register manipulation to perform integer operations on it. The last part has to do with the stack. The stack is always made up of words. If the machine's word size is 32 bit, the stack will be a stack of 32 bit values, and on a 64 bit machine they are 64 bit values. Not that you really care that much, but a 32 bit integer will be placed in a 64 bit word on the stack, and a 64 bit value, unless you're pushing a pointer to the value, will take up two words on the stack.

If you select word-alignment in your compiler, it will automatically put all variable on a word boundary. This is much faster, but takes up a bit more space. Unless you're really pressed for space, you should go for the performance. Not that it's that big a difference on a CISC architecture. On RISC it made a huge difference.

Does that help?