c++ sized type (word)
Okay, so I know that we cannot rely on 'int' to have any particular size. If you need it to be exactly 32 bits, use int_32_t (or the like).
Here's my question - what if I need a type whose size is exactly equal to the word size of the processor? On a 32-bit machine, it should be 32 bits, 64 on 64-bit, 8 bits on a little PIC, etc. Is 'int' guaranteed to be the word size? I know it usually works out that way, but I'm really looking for portability. |
Quote:
Code:
intptr_t Code:
uintptr_t |
AFAIK, that will be based on the kernel's pointer size, meaning a 32-bit kernel on a 64-bit machine will have a 32-bit pointer size.
ta0kira |
That's exactly what int is supposed to mean, the native CPU word size. I'm not sure, but x86_64 uses a 32-bit int for backwards compatibility, but in that case you could kind of see that processor as having two native word sizes, for some warped definition of "native".
|
Quote:
|
Quote:
Code:
#include <stdio.h> ta0kira |
As I understand the distinction, the x86 / x86_64 is a special case, because the designers of x86_64 intentionally made it backwards compatible. If my understanding is correct, one can run (on x86_64 hardware) a 32-bit program on a 32-bit OS, a 32-bit program on a 64-bit OS, and a 64-bit program on a 64-bit OS. If the OS is 32 bit, then 32 bits is indeed the size I want.
Essentially, what I really want is the largest size such that I can be relatively certain that there is a pretty direct mapping between my code and assembly. I'm trying to move data around memory as fast as I can. If I use a type too small, the compiler is doing a bunch of work to adjust the size of my variables to match word size/alignment/etc. If it's too big, the compiler will generate code to split it into two smaller types, which is no good either. I would just write it in assembly, except that I would like it to be portable. EDIT: And yes, I know about memcpy(), memmove(), and friends. I'm doing some pretty low-level stuff, and I need a bit more flexibility, such as the ability to bail out midway, etc. |
Quote:
Quote:
Also, there are other things to take into account besides pointer size. For example, some arches have vector ops which allow for operations on two to four intptr_t’s at a time (e.g., SSE for x86 and altivec for ppc). |
Btw, I forgot to say that most modern 64-bit Unix arches use the LP64 model (this includes sparc64, ia64, ppc64, ALPHA, HPPA, and x86-64). The only ILP64 machines I can think of are Cray-variants.
|
Quote:
gives a nice neat one-to-one correspondence between integer sizes and C keywords. If int were 64-bits, then you'd need a name for int32_t: "short" would work, but then what would you call int16_t? "short short"? |
Quote:
Here's a trivia question for anyone who knows. char is not required to be 8 bits, is it currently (within the last 15 years) implemented as anything else? |
I believe it's been implemented as 7 bits. AFAIK unsigned char needs to be 8 bits, at least in C++. Could be wrong.
ta0kira |
Quote:
edit: And just for confirmation Quote:
|
Quote:
Btw, long long is guaranteed to be at least 64 bits. |
All times are GMT -5. The time now is 03:28 PM. |