x32允许使用运行在x86_64处理器上的32位整数、长整数和指针编写程序。在某些用例下使用x32有很多好处。(x32不同于x86或x64;有关详细信息,请参见Difference between x86, x32, and x64 architectures)。
似乎有些Windows企业服务器支持x32,但我在查找有关它的详细信息时遇到了问题。这是基于一些英特尔的PDF文件,如Intel® Xeon® Processor E5-2400 Series-based Platforms for Intelligent Systems:
微软关于Predefined Macros的文档列出了常见的嫌疑犯,比如_M_X64
和_M_AMD64
。但它似乎没有讨论x32的架构选项。
如果微软支持x32,那么我怀疑它将是一个类似于大地址空间感知或终端服务感知的选项。
微软是否真的支持x32(而不是x86和x64)?
如果是,我如何确定何时在windows下选择x32?
如果不是,那么英特尔为什么要专门调用用于windows的x32平台呢?
最佳答案
问题
微软是否真的支持x32(而不是x86和x64)?
回答问题
答案是“不,微软不支持”,预处理器宏不会导致对x32的任何标识,命令行选项和ide选项不存在,标识这种编译器的字符串也不存在。
漫长的回答-第一部分
“x32没有头字符串”
无视以下事实:
没有官方文件证明这一点,
在visual studio中没有启用/禁用它的选项,并且cl.exe /?
没有这种选择的迹象,strings -el clui.dll
也不显示匹配的头字符串的符号:
4Microsoft (R) C/C++ Optimizing Compiler Version %s
-for Microsoft (R) .NET Framework version %s
(Microsoft (R) C/C++ Optimizing Compiler
FMicrosoft (R) C/C++ Optimizing Compiler Version %s for MIPS R-Series
)Microsoft (R) MIPS Assembler Version %s
CMicrosoft (R) C/C++ Optimizing Compiler Version %s for Renesas SH
<Microsoft (R) C/C++ Optimizing Compiler Version %s for ARM
:Microsoft (R) C/C++ Standard Compiler Version %s for x86
<Microsoft (R) C/C++ Optimizing Compiler Version %s for x86
GMicrosoft (R) 32-bit C/C++ Optimizing Compiler Version %s for PowerPC
@Microsoft (R) C/C++ Optimizing Compiler Version %s for Itanium
<Microsoft (R) C/C++ Optimizing Compiler Version %s for x64
>Microsoft (R) C/C++ Optimizing Compiler Version %s for ARM64
Microsoft (R) MIPS Assembler
在
strings -el "%VCINSTALLDIR%\bin\1033\clui.dll" | find "Microsoft (R)"
和bin\x86_amd64\1033\clui.dll
文件中也可以看到相同的输出,所以并不是只有一个文件没有包含它。漫长的答案-第二部分
“Windows不做数据模型”
假设是这样。你怎么能发现?在glibc的情况下,
bin\x86_arm\1033\clui.dll
定义为x32和x86,而__ILP32__
定义为amd64,表示the data model used。此外,还将为AMD64体系结构定义__LP64__
。如果定义了__x86_64__
并且定义了__x86_64__
,则使用的是x32 abi,否则使用的是amd64 abi。对C来说,这才是最重要的。如果使用的是汇编代码,那么x32 abi和x86 abi之间的区别就很重要,因此检查__ILP32__
以确定目标体系结构是64位的,检查__x86_64__
以确定32位或64位abi是否正在使用。例如:#ifdef __x86_64__
# ifdef __ILP32__
// Use X32 version of myfunc().
extern long myfunc_x32 (const char *);
long (*myfunc)(const char *) = myfunc_x32;
# else /* !__ILP32__ */
// Use AMD64 version of myfunc().
extern long myfunc_amd64 (const char *);
long (*myfunc)(const char *) = myfunc_amd64;
# endif /* __ILP32__ */
/* !__x86_64__ */
#elif defined __i386__
// Use x86 version of myfunc().
extern long myfunc_x86 (const char *);
long (*myfunc)(const char *) = myfunc_x86;
/* !__i386__ */
#else
// Use generic version of myfunc() since no optimized versions are available.
long myfunc(const char *);
#endif /* __x86_64__ */
但是,在windows上没有宏指示数据模型。您的目标是以下体系结构之一:
32位x86(
__ILP32__
)64位AMD64(
_M_IX86
/_M_AMD64
)(32位?)ARM(
_M_X64
)理论上可以独立使用
_M_ARM
和_M_AMD64
来确定x32是否存在,但如果定义了_M_X64
,则也定义了_M_AMD64
。漫长的答案-第三部分
“坏消息”
最后,在搜索到任何东西(甚至可能是被遗忘已久的材料)之后,没有证据表明windows支持或曾经支持为类似linux的x32 abi编写代码。预处理器宏对标识x32没有帮助,命令行选项和ide选项不存在,标识此类编译器的字符串也不存在。
漫长的答案——新的希望破灭了
“这些不是您要查找的宏”
人们可以假设使用当前存在的宏进行检查,但在这种情况下却没有帮助,因为x32 for windows不存在。这与glibc检查没有什么不同,但是如果定义了
_M_X64
而不是启用x32,如果没有定义__ILP32__
则启用x32。#ifdef _M_AMD64
# ifndef _M_X64
# define ABI_STR "X32"
# else
# define ABI_STR "AMD64"
# endif
#elif defined _M_IX86
# define ABI_STR "X86"
#else
# error unsupported CPU/architecture
#endif
当然,如果定义了
_M_X64
,那么也定义了_M_AMD64
,进一步加强了没有针对windows的x32的证据。关于windows - 如何在Windows上检测X32?,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/32675300/