检测CPU架构编译时
编译 C 或 C++ 代码时找出 CPU 架构的最可靠方法是什么? 据我所知,不同的编译器有自己的一组非标准预处理器定义(MSVS中的_M_X86
,GCC中的__i386__
,__arm__
, ETC)。
是否有一种标准方法来检测我正在构建的架构? 如果没有,是否有各种编译器的此类定义的完整列表的来源,例如包含所有样板#ifdef 的标头?
What is the most reliable way to find out CPU architecture when compiling C or C++ code? As far as I can tell, different compilers have their own set of non-standard preprocessor definitions (_M_X86
in MSVS, __i386__
, __arm__
in GCC, etc).
Is there a standard way to detect the architecture I'm building for? If not, is there a source for a comprehensive list of such definitions for various compilers, such as a header with all the boilerplate #ifdef
s?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(8)
如果您想要交叉编译器解决方案,则只需使用
Boost.Predef
其中包含BOOST_ARCH_
。BOOST_COMP_
表示正在使用的编译器。BOOST_LANG_
用于编译所依据的语言标准。BOOST_LIB_C_
和BOOST_LIB_STD_
用于使用的 C 和 C++ 标准库。BOOST_OS_
表示我们要编译到的操作系统。BOOST_PLAT_
适用于操作系统或编译器之上的平台。BOOST_ENDIAN_
用于操作系统和架构组合的字节顺序。BOOST_HW_
用于硬件特定功能。BOOST_HW_SIMD
用于 SIMD(单指令多数据)检测。请注意,虽然 Boost 通常被认为是 C++ 库,但
Boost.Predef
是纯头文件,并且适用于 C例如,
您可以了解有关如何使用的更多信息这里
Godbolt 上的演示
If you want a cross-compiler solution then just use
Boost.Predef
which containsBOOST_ARCH_
for system/CPU architecture one is compiling for.BOOST_COMP_
for the compiler one is using.BOOST_LANG_
for language standards one is compiling against.BOOST_LIB_C_
andBOOST_LIB_STD_
for the C and C++ standard library in use.BOOST_OS_
for the operating system we are compiling to.BOOST_PLAT_
for platforms on top of operating system or compilers.BOOST_ENDIAN_
for endianness of the os and architecture combination.BOOST_HW_
for hardware specific features.BOOST_HW_SIMD
for SIMD (Single Instruction Multiple Data) detection.Note that although Boost is usually thought of as a C++ library,
Boost.Predef
is pure header-only and works for CFor example
You can find out more on how to use it here
Demo on Godbolt
没有编译器间的标准,但每个编译器往往非常一致。 您可以为自己构建一个如下所示的标头:
全面的列表没有多大意义,因为有数千种编译器,但广泛使用的只有 3-4 个(Microsoft C++、GCC、Intel CC,也许是 TenDRA?)。 只需决定您的应用程序将支持哪些编译器,列出它们的#defines,并根据需要更新您的标头。
There's no inter-compiler standard, but each compiler tends to be quite consistent. You can build a header for yourself that's something like this:
There's not much point to a comprehensive list, because there are thousands of compilers but only 3-4 in widespread use (Microsoft C++, GCC, Intel CC, maybe TenDRA?). Just decide which compilers your application will support, list their #defines, and update your header as needed.
如果您想转储特定平台上的所有可用功能,您可以运行 GCC,如下所示:
它将转储诸如
#define __SSE3__ 1
、#define __AES__ 1
等宏。If you would like to dump all available features on a particular platform, you could run GCC like:
It would dump macros like
#define __SSE3__ 1
,#define __AES__ 1
, etc.享受吧,我是这个的原作者。
Enjoy, I was the original author of this.
此处有一个
#define
列表。 之前有一个高度投票的答案包含此链接,但它被 mod 删除了,大概是由于 SO 的“答案必须有代码”规则。 这是一个随机样本。 点击链接查看完整列表。AMD64
__amd64__
__amd64
__x86_64__
__x86_64
_M_X64< /code>
_M_AMD64
There's a list of the
#define
s here. There was a previous highly voted answer that included this link but it was deleted by a mod presumably due to SO's "answers must have code" rule. So here's a random sample. Follow the link for the full list.AMD64
__amd64__
__amd64
__x86_64__
__x86_64
_M_X64
_M_AMD64
没有什么标准。 Brian Hook 在他的“Portable Open Source Harness”中记录了其中的一些内容,甚至尝试将它们变成连贯且可用的东西(ymmv 对此)。 请参阅他的存储库中的 posh.h 标头:
There's nothing standard. Brian Hook documented a bunch of these in his "Portable Open Source Harness", and even tries to make them into something coherent and usable (ymmv regarding that). See the posh.h header on his repo:
我的旋转 使用
文件
arm.h
文件
x86_64.h
文件
x86_32.h
My spin at it
Usage
File
arm.h
File
x86_64.h
File
x86_32.h
如果您需要对 CPU 功能进行细粒度检测,最好的方法是同时提供一个 CPUID 程序,该程序将 CPU 支持的功能集输出到 stdout 或某些“cpu_config.h”文件。 然后将该程序与您的构建过程集成。
If you need a fine-grained detection of CPU features, the best approach is to ship also a CPUID program which outputs to stdout or some "cpu_config.h" file the set of features supported by the CPU. Then you integrate that program with your build process.