Do I need to have 64 bit Processor to use 64 bit data type

转

http://stackoverflow.com/questions/5530906/do-i-need-to-have-64-bit-processor-to-use-64-bit-data-type 

I have a few questions:

1. Do I need to have 64 bit Processor to use 64 bit data type(__int64 or int64_t) ?

2. What means by, the "t" of int64_t?

3. Starting from what version of GCC and VCC are supporting data type?

4. Is the 64 bit data type are just doubling the data length or there are some other things going under the hood too?

4 Answers

up vote7 down voteaccepted

You don't need 64 bit processor to use 64 bit data type. It all depends on the compiler and only on the compiler. The compiler can provide you with 128-bit, 237-bit or 803-bit data types, if it so desires.

However, keep in mind that normally 32-bit CPUs cannot handle 64-bit values directly, which means that the burden of supporting all necessary language operations for 64-bit type lies on the compiler. The compiler will have to generate a more-or-less complex sequence of 32-bit CPU instructions in order to perform additions, shifts, multiplications etc. on 64-bit values. This means that in code generated for 32-bit CPUs basic language operations on 64-bit data types will not be as efficient as they would be in code generated for 64-bit CPUs (since in the latter most language operations would be carried out by a single CPU instruction).

The "t" in int64_t stands for either "type" or "typedef name". That's an old accepted naming convention for standard library typedefs.

As for compiler versions, it is an ambiguous question actually. The typedef name int64_t is a part of the standard library of C language (but not of C++ language), while the support for 64-bit integer types (under any name) is a part of the compiler. So which one are you asking about? For example, MSVC compiler has been supporting 64-bit data types for a long time, but the names for these types have been different. 64-bit signed integer is called __int64 of something like that in MSVC. As for the int64_ttypedef, AFAIK, it is not a part of MSVC's standard library even today. In fact, int64_t became a part of C language from the C99 version of its specification. At the same time it is not a part of C++ language. So, generally, you are not supposed to expect to have int64_t in C++ code regardless of the version of the compiler.

As for data length... Well, yeah, it is just doubling the number of bits. The rest follows.

http://stackoverflow.com/questions/2692329/int64-on-a-32-bit-machine 

In this case, it uses 2 32-bit memory addresses to form a 64-bit number together. Addition/substraction is easy, you do it by parts, the only gotcha is taking the carry-over from the lower part to the higher part. For multiplication/division, it's harder (ie more instructions).

It's obviously slow, quite a bit slower than 32 bit arithmetic for multiplication, but if you need it, it's there for you. And when you upgrade to a 64-bit processor compiler, it gets automatically optimized to one instruction with the bigger word size.

The Visual Studio 2010 Professional implementation of 64 bit multiplication on a 32-bit processor, compiled in release mode, is:

_allmul PROC NEAR

A       EQU     [esp +4]      ;stack address of a
B       EQU     [esp +12]     ;stack address of b

        mov     eax,HIWORD(A)
        mov     ecx,HIWORD(B)
        or      ecx,eax         ;test forboth hiwords zero.
        mov     ecx,LOWORD(B)
        jnz     shorthard      ;both are zero,just mult ALO and BLO

        mov     eax,LOWORD(A)
        mul     ecx

        ret     16             ;callee restores the stack

hard:
        push    ebx

A2      EQU     [esp +8]      ;stack address of a
B2      EQU     [esp +16]     ;stack address of b

        mul     ecx             ;eax has AHI,ecx has BLO,so AHI *BLO
        mov     ebx,eax         ;save result

        mov     eax,LOWORD(A2)
        mul     dword ptr HIWORD(B2);ALO *BHI
        add     ebx,eax         ;ebx =((ALO *BHI)+(AHI *BLO))

        mov     eax,LOWORD(A2) ;ecx =BLO
        mul     ecx             ;so edx:eax =ALO*BLO
        add     edx,ebx         ;now edx has all the LO*HI stuff

        pop     ebx

        ret     16             ;callee restores the stack

As you can see, it's a LOT slower than normal multiplication.