标签：
之前转的:
之前对于x64平台的移植都是纸上谈兵,算是前期准备工作, 但起码在写代码时,已经非常注意了.所以现在移植起来相对很顺利.昨天用了一天时间把自己代码添加了x64支持.
贴一下遇到的问题,就作为注意事项吧,以下文字来自我的cnblogs博客的另一文章,有修改
1.指针到数值的转换.
指针 (如void*)转到数值,要用intptr_t或者uintptr_t (用Win32的INT_PTR也可以,当然用C/C++标准的更好),而不使用int/uint/DWORD, 因为x64平台下的void*或者任何指针都是64位的, 转到DWORD(win x64的LLP64下的long,32位)就被截断到32位了,如果再转到64位的指针,就丢失了高双字的部分.
这个问题在"跨平台编程注意事项(一)"提到过, 目前基本没有遇到,因为之前的编码已经很注意这个问题了.但是有两行跟FreeImage相关的AlignedMalloc代码,直接复制FreeIamge里面的AlignedMalloc,他用的是void*-->unsigned long,当时直接Ctrl+V,没仔细看,所以这里程序就崩溃了.
2.内存边界对齐的问题.
目前Win32下 VC10默认对齐到8字节,x64对齐到16字节.
因为之前的内存管理没有考虑x64平台的内存对齐,所以会有一些问题.遇到的一个问题就是libPNG(FreeImage的依赖)中使用的setjmp(作为一个C++程序猿, setjmp/longjmp我从来不用的),执行到读写FPU状态标记FNSTCW(一个WORD)和MMX指令就崩溃,提示内存读0地址,但是看内存是好好的,调试了半天找不到原因,最后看了下创建的(我的内存管理给分配的)pngstruct没有对齐到16字节边界,导致setjmp的参数没有对齐.尝试性的试了下,居然好了.怀疑是读写非对齐内存的问题,但记得x86下不对齐只会有性能损失,x64会出错么? 不太了解,有空了再多搜搜文档,了解下.
目前解决方案是,内存管理模块会根据目标平台,选择对应的对齐大小.
3.Win32下的各种API.
一些MFC的三方库没有用DWORD_PTR和INT_PTR作为参数.其他主要是GetWindowLongPtr这类,看msdn上说要用这个保持x86/x64兼容,这个早已经用了,但没发现对应的宏,GWL_XXX的对应要用GWLP_XXX的版本,这个一开始也是觉得诡异,怎么x64下没有这个宏了,不知道有什么问题,后面google了一下就出来了,相对比较简单.
4.内联汇编.
在MSVC的x64编译器不支持内联汇编了(以后可能会支持?),这个以前不知道,还傻乎乎写了64位的内联汇编,后来在贴吧知道了,就把预先写的64位内联汇编删除了...其实也没怎么用内联汇编,主要就是同步锁用了lock cmpxchg,以及原子操作用了lock xadd等等,解决方法也很简单,去掉所有内联汇编,用MSVC的intrins: _InterlockedCompareExchange / _InterlockedCompareExchange64 一族和GCC的built-in: __sync_fetch_and_add / __sync_add_and_fetch / __sync_bool_compare_and_swap一族.
[百度空间] [原]跨平台编程注意事项(二): windows下 x86到x64的移植
标签：
原文地址：http://www.cnblogs.com/crazii/p/4512772.html
