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

Question

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

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

1. 指令集如何影响需要哪个编译器？它取决于实际指令集还是仅取决于其寄存器大小(16/32/64位)？如果它只取决于它是64位还是32位，那么指令集看上去就不一样了，机器代码就不能正常工作吗？我对此感到困惑，因为提供的应用程序总是有32位和64位的版本，即使有几个可能的指令集。
2. 运行在特定指令集之上的操作系统是否会影响需要哪个编译器，以及为什么？如果CPU是相同的，那么机器代码不是相同的吗？

更新

感谢所有回答我的人。我的最后结论

Answer 1

指令集如何影响需要哪个编译器？

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

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

两者都有。

如果它只取决于它是64位还是32位，那么指令集看上去就不一样了，机器代码就不能正常工作吗？我对此感到困惑，因为提供的应用程序总是有32位和64位的版本，即使有几个可能的指令集。

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

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

指令集是相同的，但是与操作系统对话的方式是不同的。原则上，您可以在linux上运行一个windows应用程序，如果它们都运行在相同的规范集上，但是，应用程序会说“打开该文件的窗口”，而linux不知道该做什么。酒项目通过将"windows打开该文件“转换为"linux打开该文件”来填补这个空白，并在linux下运行windows应用程序，如果需要实现更多的windows特定功能，这会变得非常复杂。

Answer 2

1. 这肯定取决于你的程序将运行的机器。不仅在8/16/32/64寄存器上，而且(更重要的是)在指令集本身上。如果您尝试在32位ARM处理器上运行32位x86程序，当然它不会工作。这仅仅是因为机器代码在每个体系结构上都非常具体，因此定义了哪个位会/意味着什么。即使某些指令的长度可能是相同的，操作数排序可能是不同的，或者某些位可能有不同的含义，或者(很可能)操作码本身可能完全不同。因此，MOV在x86上的操作代码可能与不同体系结构上的BLOWUPTHEWORLD相同。这就是为什么每个体系结构都有特定的编译器。嵌入式系统(从平面控制器到RaspberryPis到控制玩具汽车的AVR)几乎每个处理器/微控制器家族都有不同的编译器。 在大多数应用程序中，除了32位和64位之外，其他的区别在某种程度上是由操作系统屏蔽的，因为操作系统的任务之一是提供抽象(考虑系统调用，比如open处理文件)，而不管底层指令的含义如何(从底层指令的角度来看)。32位vs 64位是一个差异，甚至一个操作系统也不可能隐藏。
2. 是。考虑一下动态库。微软的DLL肯定不会在Linux上工作，除非有人手动解码它们。反之亦然，Linux上的共享对象(.so)不能简单地在Windows上工作，因为它们是以完全不同的方式构建的。