[Baidu Space] [Original] cross-platform programming Considerations (II): Migration from Windows x86 to x64

Before the turn:

Porting a program to a 64-bit Windows

And a piece of my own writing:

Cross-platform programming considerations (i)

Prior to the x64 platform for the transplant is on paper, as a preparatory work, but at least in writing code, has been very careful. So now the transplant is relatively smooth. Yesterday took a day to add their own code x64 support.
Post the problem, as a matter of caution, the following text from my Cnblogs blog Another article, there are changes

1. Pointer-to-value conversions.

Pointers (such as void*) go to numeric values, use intptr_t or uintptr_t (int_ptr with Win32, of course, better than C + + standard) instead of Int/uint/dword, because x64 under void* platform or any pointer is 64-bit, go to the DWORD (win x64 LLP64 under the long,32 bit) is truncated to 32 bits, if you go to the 64-bit pointer, you lose the high-double-word part.

This issue is mentioned in the "cross-platform programming considerations (i)", which has not been encountered at the moment, because the previous coding has already paid attention to this problem. But there are two lines of Alignedmalloc code associated with Freeimage, Directly copy freeiamge inside of the Alignedmalloc, he used is void*-->unsigned long, then directly Ctrl + V, did not look carefully, so here the program collapsed.

2. Memory boundary alignment issues.

Currently Win32 VC10 is aligned to 8 bytes by default, x64 to 16 bytes.
Because previous memory management did not take into account the x64 platform's memory alignment, there were some problems. One of the problems encountered was the setjmp used in Libpng (Freeimage dependency) (as a C + + program ape, setjmp/longjmp I never had), Execute to read/write FPU status tag FNSTCW (a word) and MMX instructions crash, prompt memory to read 0 address, but look at memory is good, debugging for half a day to find the reason, finally looked under the creation (my memory management to allocate) pngstruct not aligned to 16 byte boundary, The parameter that caused the setjmp is not aligned. Tried to try, incredibly well. Suspicion is the question of read and write non-aligned memory, but remember x86 under the misalignment will only have performance loss, x64 will be wrong? Do not know, have time to search more documents, understand the next.
The current solution is that the memory management module chooses the corresponding alignment size based on the target platform.

The various APIs under 3.WIN32.

Some MFC's three-party libraries do not use DWORD_PTR and int_ptr as parameters. The other main is getwindowlongptr this category, see MSDN said to use this to keep x86/x64 compatible, this has been used, but did not find the corresponding macro, Gwl_ xxx corresponding to use gwlp_xxx version, the beginning is also feel strange, how x64 under no this macro, do not know what problem, the back Google a bit out, relatively simple.

4. Inline assembly.

The x64 compiler in MSVC does not support inline assembly (which may later be supported?), this previously did not know, but also foolishly wrote the 64-bit inline assembly, later in the bar to know, the pre-written 64 inline assembly deleted ... In fact, not how to use the inline assembly, mainly is the synchronization lock with the lock CMPXCHG, and atomic operation with the lock Xadd and so on, the solution is very simple, remove all inline assembly, with msvc Intrins: _ InterlockedCompareExchange/_interlockedcompareexchange64 family and GCC built-in: __sync_fetch_and_add/__sync_add_and_ Fetch/__sync_bool_compare_and_swap family.

[Baidu Space] [Original] cross-platform programming Considerations (II): Migration from Windows x86 to x64