Compiler construction 哪些因素会影响所需的编译器？

我正在学习C语言，我不明白是什么因素决定了所需的编译器以及为什么

假设我有一个C代码，它是一个小型控制台应用程序，我想为一个特定的平台编译它。这个平台将有一个特定的操作系统和指令集

指令集如何影响所需的编译器？它是取决于实际指令集还是仅取决于其寄存器大小（16/32/64位）？如果它只取决于它是64位还是32位，那么指令集是否看起来不同，机器代码是否因此无法工作？我对此感到困惑，因为一个应用程序总是有32位和64位版本，即使有几种可能的指令集

在特定指令集上运行的操作系统会影响需要哪个编译器吗？为什么？如果CPU是相同的，那么机器代码不是相同的吗

---

更新

感谢所有回答的人。 我的

这完全取决于您的程序将运行的机器。不仅在8/16/32/64寄存器上，而且（更重要的是）在指令集本身上。如果您试图在32位ARM处理器上运行32位x86程序，那么它当然不会工作。这仅仅是因为机器代码在每个体系结构上都非常具体，因此定义了哪个位做什么/意味着什么。尽管某些指令的长度可能相同，但操作数顺序可能不同，或者某些位可能具有不同的含义，或者（很可能）操作码本身可能完全不同。因此，x86上的

MOV

可能与不同架构上的

BLOWUPTHEWORLD

具有相同的操作代码。这就是为什么每个体系结构都有特定的编译器。嵌入式系统（想想从平面控制器到树莓到控制玩具车的AVR的所有东西）几乎每个处理器/微控制器家族都有不同的编译器

在大多数应用程序中，32位与64位之间的差异在某种程度上被操作系统屏蔽了，因为操作系统的任务之一是提供抽象（想想系统调用，比如

打开

文件），而不管下面的意思是什么（从低级指令的角度来看）。32位对64位是一个区别，即使操作系统可能不会隐藏

对。考虑一下动态库。微软的DLL肯定不会在Linux上运行，除非有人手动解码。相反，Linux上的共享对象（.so）无法在Windows上工作，因为它们是以完全不同的方式构建的

---

您提到的所有因素对您选择编译器都很重要。指令集、ABI（包括寄存器大小）、试图部署到的操作系统以及要在其上运行编译器的操作系统。您可以在同一台机器上运行不同的操作系统（例如，购买一台iMac，您可以安装MacOS、多种Linux、多种Unix或Windows），因此单靠CPU还不足以决定您需要什么编译器。有时，您可以使用同一个编译器，只需要一组不同的头文件就可以访问操作系统的功能

但是，这并不保证选择特定的编译器。编译器本质上只是一个应用程序。将文本转换成机器代码的转换器。因此，有许多编译器可以在多个平台上运行（即ABI、OS和CPU的组合），也有许多编译器可以为多个平台生成可执行文件。对于一些较小的CPU和操作系统（例如嵌入式CPU），有时只有一个编译器

指令集如何影响所需的编译器

如果处理器有不同的指令集，编译器需要生成不同的指令。大多数编译器支持多个指令集，因此您可能不需要仅仅因为指令集发生更改就更改编译器

它是取决于实际指令集还是仅取决于其寄存器大小（16/32/64位）

两者都有

如果它只取决于它是64位还是32位，那么指令集是否看起来不同，机器代码是否因此无法工作？我对此感到困惑，因为一个应用程序总是有32位和64位版本，即使有几种可能的指令集

虽然有不同的指令集x86和x64主导桌面市场，但大多数软件供应商认为不需要支持其他任何东西

在特定指令集上运行的操作系统会影响需要哪个编译器吗？为什么？如果CPU是相同的，那么机器代码不是相同的吗

---

指令集相同，但与操作系统的对话方式不同。原则上，如果windows应用程序在同一指令集上运行，则可以在linux上运行windows应用程序，但是，应用程序会显示“windows打开该文件”，linux不知道该做什么。该项目通过将“windows打开该文件”转换为“linux打开该文件”，填补了这一空白，并在linux下运行windows应用程序如果需要实现更多特定于windows的功能，这将变得复杂。

因此标记为64位的Intel和AMD CPU很可能具有x64指令集？@MinecraftShamrock它们具有相同的基本指令集。它们在一些方面有点不同，但通常在运行时检测到。来自intel的指令集不同，因此intel/AMD x64不保证兼容性。当检测到这些差异时，操作系统是否能够补偿这些差异？假设我们有一个适用于64位Windows 7的应用程序的下载链接，那么它是为Intel x64还是AMD x64编译的，因为操作系统对其进行了补偿，这是否相等？正如您前面提到的，这些支持多个指令集的编译器能否生成ap