为什么C编译器这么少？

C是世界上使用最广泛的语言之一。它占现有代码的很大一部分，并继续用于大量的新代码。它受到用户的喜爱，它的广泛移植使能够运行C对许多平台的非正式定义而言，并因其是一种具有相对简洁功能的“小型”语言而受到其粉丝的称赞。

那么所有的编译器在哪里？

在桌面上，（实际上）有两个：GCC和Clang。考虑了几秒钟，您可能会记得英特尔也存在。还有很多其他的东西，对于普通人来说实在太晦涩难懂了，几乎没有普遍地去支持最新的语言版本（甚至常常是定义明确的语言子集，只是“子集”）。此列表的一半成员是历史脚注；其余大多数都是非常专业的，实际上还没有实现完整的语言。实际上很少有开源的。

Scheme和Forth-其他深受其迷们喜爱的小语言-可能比实际用户拥有更多的编译器。甚至像SML之类的东西，也要比C有更多“严肃”的实现方式可供选择。而针对验证的新的（未完成的）C编译器的发布实际上看到了一些相当负面的回应，而资深的实现则努力争取足够的贡献者甚至赶上C99。

为什么？实现C这么难吗？不是C ++。用户是否只是对其所属的复杂度组有一个非常歪斜的想法（即实际上它比Scheme更接近C ++）？

如今，您需要一个真正的C编译器作为优化编译器，尤其是因为C不再是一种与硬件接近的语言，因为当前的处理器非常复杂（乱序，流水线，超标量，具有复杂的缓存和TLB，因此需要指令调度等）。即使今天的x86处理器都能够运行相同的机器代码，也不像上世纪的i386处理器那样。请参阅David Chisnall撰写的C语言不是低级语言（您的计算机不是快速的PDP-11）。

很少有人在使用像tinycc或nwcc这样的天真非优化C编译器，因为它们生成的代码比优化编译器所提供的代码慢几倍。

编码优化编译器很困难。请注意，GCC和Clang都在优化某些“源语言无关”的代码表示形式（GCC为Gimple，Clang为LLVM）。一个好的C编译器的复杂性不在解析阶段！

特别是，制作C ++编译器并不比制作C编译器难：解析C ++并将其转换为某些内部代码表示很复杂（因为C ++规范很复杂），但是众所周知，但是优化部分更加复杂复杂（在GCC内部：中端优化，源语言和目标处理器中立，构成了编译器的主要部分，其余部分在几种语言的前端和若干处理器的后端之间保持平衡）。因此，大多数优化的C编译器也能够编译其他一些语言，例如C ++，Fortran，D，... GCC的C ++特定部分大约占编译器的20％...

同样，C（或C ++）的使用如此广泛，即使人们没有完全遵循正式的标准（人们对语言的语义定义不够准确），人们也希望他们的代码是可编译的（因此每个编译器可能都有自己的解释方法）的）。还要查看CompCert证明的C编译器和Frama-C静态分析器，它们关心C的更正式语义。

优化是一个长尾现象：实现一些简单的优化很容易，但是它们不会使编译器具有竞争力！您需要实现许多不同的优化，并巧妙地组织和组合它们，以获得具有竞争力的真实编译器。换句话说，现实世界中的优化编译器必须是复杂的软件。顺便说一句，GCC和Clang / LLVM都有几个内部专用的C / C ++代码生成器。两者都是巨大的野兽（数百万个源代码行，每年以百分之几的速度增长），拥有庞大的开发人员社区（数百人，大部分时间是全职或至少一半时间）。

请注意，有没有（据我所知）多线程的C编译器，即使一些编译器的部分可以并行运行（如程序内优化，寄存器分配，指令调度...）。与之并行构建make -j并不总是足够的（尤其是LTO）。

另外，很难从头开始为C编译器的编码提供资金，并且这种工作需要持续数年。最后，当今大多数C或C ++编译器都是自由软件（新兴公司不再有新的专有编译器市场，或者至少是垄断商品（如Microsoft Visual C ++）），并且几乎免费成为编译器所需要的软件（因为他们需要来自许多不同组织的捐款）。

我很高兴获得从头开始作为免费软件在C编译器上工作的资金，但是我还不够天真地相信今天有这种可能！

我想反驳您的基本假设，即只有少量的C实现。

我什至不了解C，不使用C，我也不是C社区的成员，但是，即使您所提到的少数几个编译器，我的知识也要多得多。

首先，最重要的是，该编译器可能完全使台式机上的GCC和Clang相形见Microsoft：Microsoft VisualC。尽管OSX和Linux都在台式机上取得了长足的进步，而iOS和Android的市场份额却“被盗”与以前的传统桌面用户不同，Windows仍然是主要的桌面操作系统，大多数Windows桌面C程序可能都是使用Microsoft工具编译的。

传统上，每个OS供应商和每个芯片供应商都有自己的编译器。Microsoft作为OS供应商，具有Microsoft VisualC。IBM作为OS供应商和芯片供应商，都具有XLC（这是AIX的默认系统编译器，以及用于编译AIX和i / OS的编译器） 。英特尔拥有自己的编译器。Sun / Oracle在Sun Studio中拥有自己的编译器。

然后，有像PathScale和Portland Group这样的高性能编译器供应商，它们的编译器（和OpenMP库）用于数字处理。

Digital Mars仍在营业。我相信Walter Bright的独特之处在于，他是地球上唯一一个亲自（主要是）自己创建了生产质量C ++编译器的人。

最后但并非最不重要的一点是，我们拥有用于嵌入式微控制器的所有专有编译器。IIRC，在整个计算历史的总和中，每年售出的微控制器数量超过台式机，移动设备，服务器，工作站和大型机CPU。因此，这些绝对不是利基产品。

荣誉奖是TruffleC，它是使用Truffle AST解释器框架在JVM（！）上运行的C 解释器（！），其运行速度仅比GCC和Clang（在任何给定的基准测试中最快）低7％。计算机语言基准测试，并且比两者都更快。使用TruffleC，Truffle团队能够获得他们的JRuby + Truffle版本，以比实际的C Ruby实现更快地执行Ruby C扩展！

因此，除了您列出的实现之外，这还有6种实现，我什至不知道C就能知道。

您需要多少个编译器？

如果它们具有不同的功能集，则会造成可移植性问题。如果它们被商品化，则可以选择“默认”（GCC，Clang或VS）。如果您关心最后5％的性能，则可以进行基准测试。

如果您是出于休闲目的或出于研究目的而进行编程语言工作，则可能使用的是更现代的语言。因此，用于Scheme和ML的玩具编译器激增。尽管OCaml似乎在非玩具非学术用途中获得了一定的吸引力。

请注意，这会因语言而异。Java本质上具有Sun / Oracle工具链和GNU。Python具有各种编译器，与标准解释器相比，这些编译器均未得到真正的尊重。Rust和Go分别只有一个实现。C＃具有Microsoft和Mono。

C / C ++在编译语言中是唯一的，因为它具有3个主要规范的主要实现。

按照不使用任何不常用内容的规则，其他所有已编译语言都为0到1。

而且我认为javascript是您需要指定“已编译”的唯一原因。

那么您的目标语言是什么？

SML编译器通常针对C或LLVM之类的东西（或在您的链接中看到的JVM或JavaScript）。

如果您正在编译C，则不是因为您要使用JVM。你要比C差。差得多。然后，您需要为所有目标平台多次复制该次要地狱。

当然，C不是C ++，但我想说它比Scheme更接近C ++。它确实有其自己的未定义行为弊端的子集（我正在查看内置类型的大小）。而且，如果您弄糟了这些细节（或者“正确”但意外地做到了），那么您在重要系统上已有数十年的现有代码，可以告诉您您有多糟糕。如果您搞砸了SML编译器，它将无法正常工作- 可能会有人注意到。有一天