我认为主要任务是解析数据并创建与其对应的汇编语言指令集（两者都是逻辑）。 这些编译器是否使用除此之外的任何其他固有C功能？ 我的意思是我可以编写一个程序，可以在X语言中使用我的程序并使其成为类似C的程序，然后使用gcc编译 - 后端也发生了一切 - 但这种方法是否明智？ 我的问题的图形表示是：
语言X - 使用C的字符串处理和解析功能在C中编写的编译器在机器上创建ASM - RUn 特点：使用C的基本机制不再生成汇编代码 - 最后使用自己的汇编逻辑。
语言X - 用C编写的编译器再次将其重新编码为C语法 - 将其提供给GCC，如编译器 - ASM - 机器代码
特征 ：
愚蠢的系统，因为它最终使用C的设施
答案 0 :(得分：3)
你非常错误地认为编译器的两个主要任务是“编写解析器”和“将输出写入汇编器”。最有趣的事情发生在中间，验证传递（类型检查），分析传递（各种信息收集以进一步优化）和转换传递（从高级语言到较低级别的语言，直到在某个阶段之后你完成某事看起来像集会。）
即使您设计了一个简单的编译器（第一次不需要与GCC竞争），解析器也不应该是“主要任务”。实际上解析器现在被认为是一个相当常规的问题，至少如果你的语法相当传统（我不是在谈论疯狂的语法扩展性事物）;有一些解析器生成器工作得相对较好，你也可以使用手工解析器来获得更大的灵活性，但总而言之，它绝对不应该是问题。
编写输出C或任何其他语言的编译器是完全合理的。许多不同的编译器（例如Haskell和各种Scheme）都使用C作为目标语言。但是通常（对于有趣的语言），预先有很多工作要将编程语言的抽象编译成可以转换为C的更低级别的东西。
现在还有其他方法可以从低级程序集部件中抽象出自己：您可以定位虚拟机（JVM，CLR，Erlang的VM，Parrot ......），或生成LLVM字节码等。
你在问题中提到了ML。使用代数数据类型（即SML，OCaml，Haskell等）的静态类型函数语言是编写编译器的非常好的语言;我认为最合适的。您可能对本书Modern Compiler Implementation in ML感兴趣（有C和Java的变体，但ML书是最好的一本）。它在某些地方有点专业，但是对于编译技术有一个很好的整体视图可能是一个不错的选择。当然，如果你想成为一名编译专家，你也应该使用其他参考资料，例如Dragon Book，以及可能的编译类似于你的语言的参考资料（我的意思是编译纯函数语言可能与编写命令式程序语言非常不同） ）。
答案 1 :(得分：2)
每个编译器都不同
编译器编写者可以（并且！）完成您能想到的任何事情。旧的“翻译器”f2c实际上是一个Fortran编译器，它定位（即产生输出）c。
这没有什么不妥，尽管它可以使编译过程变慢（毕竟还有一个额外的lex和parse阶段）。
另一点，对于严肃的编译器，它是操纵抽象语法树来优化大部分代码和大部分时间的输出。 Crenshaw tutorial中完成的即时代码生成与全功能编译器之间存在巨大差异。