• Welcome to Valhalla Legends Archive.
 

64 bit programs

Started by I_Smell_Tuna, May 10, 2005, 01:50 PM

Previous topic - Next topic

I_Smell_Tuna

To port a program from 32 to 64 bits do you just have to recompile it with a 64 bit compiler?

MyndFyre

There's potentially a lot more to it than that.
QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.

Yoni

Sometimes that's all you have to do.
A 64-bit compiler will compile all pointer variables as 64-bit stack variables/registers.

Note that if you code in Win32, you have to code intelligently.
Ever since Microsoft became 64-bit-aware, the Platform SDK has changed slightly. Functions and macros were added that have the word "Ptr" on the end, and it's a best practice to use them always, instead of the old ones.

Do not blindly assume in your code that the sizeof(pointer) is 4 bytes. Whenever needed, specify the sizeof operator explicitly. Don't ever perform a reinterpret cast to "long", for instance.

Example: They defined new types, "LONG_PTR" and "ULONG_PTR", that are signed/unsigned integers, respectively, with an amount of bits that depends on whether compiled in 32-bit or 64-bit mode. By definition, it will be safe to cast a pointer to ULONG_PTR and back without losing bits.

Example: Instead of GetWindowLong, use GetWindowLongPtr. This gives your window a value associated with an index label, except now the value is a LONG_PTR and not a LONG like it used to be. (You use GWLP_label instead of GWL_label, etc.)

Programmers used to assume things about pointers, such as that the most significant bit (which may falsely assumed to be "bit 31") of the pointer is always 0 in user mode and always 1 in kernel mode, and therefore it is not necessary, and something else can make good use of this bit. 64-bit compatibility is not the only reason that this assumption is terrible. Do not assume anything about the bit layout of your pointer.

A program coded intelligently, with the programmer considering the possibility of the sizeof(pointer) changing, will probably be as easy to port to a 64-bit environment as simply compiling with the compiler in 64-bit mode.

Adron

Quote from: Yoni on May 11, 2005, 06:52 AM
Do not assume anything about the bit layout of your pointer.

What you may need to do bitwise on a pointer is check for pointer alignment.

Yoni

Hmm, true. When I was writing that, I was thinking of the more significant bits, not the less significant bits.

Ok, assume something about the bit layout of your pointer if and only if it is required by the situation. :P