Aros/开发人员/LLVM
LLVM 是一个编译器框架。像 GCC 一样，它为不同的解析器提供前端。(C 和 C++ 使用 Clang 前端，而 GCC 则有自己的前端，例如 G++ 用于 C++，G77 用于 Fortran。) 所有支持的语言都使用一个通用的优化阶段。后端支持不同类型的处理器。(x86、AMD64、PPC 和 ARM 都受到 GCC 和 LLVM 的支持。) 为了使 Clang C/C++ 编译器和其他基于 LLVM 的编译器能够与 AROS 68k 协同工作，我们需要为 68k 处理器创建一个 LLVM 后端。
此外，LLVM 框架相对于 GCC 框架有一些优势：LLVM 具有 JIT 编译模式，因此可用于创建 Java 虚拟机，而 GCJ 不支持 JIT 编译；LLVM 的 JIT 也用于 Mesa 着色器模拟，用于不支持着色器的显卡；LLVM 完全用 C++ 编写，因此更容易修改；最后，LLVM 生成代码的速度比 GCC 快。缺点是 LLVM 的代码生成器效率略低于最新版本的 GCC，而 GCC 已经存在 68k 后端。
AROS 应该使用 LLVM 的原因是，GCC 的开发者常常不想“浪费”时间在 68k 后端上，因为他们可以把时间花在更现代的处理器上，所以他们会拒绝那些会使后端更好的补丁。LLVM 具有用于其内部机器语言表示的比特码文件格式，因此一旦解决字节序和内存对齐问题，它就可以从内部表示运行代码。
如果你指的是错误消息，那么答案是肯定的。Clang 的错误输出更具描述性，通常会将错误追溯到发生错误行的单个词素。如果你指的是“调试输出”作为调试应用程序，那么 LLDB 调试器目前仅适用于 Macintosh 和可能适用于 Linux。它仍处于开发的早期阶段。在其他系统上，GDB 仍然是 LLVM 输出的唯一调试器。
作为额外的优势，LLVM 被设计为一套库，因此它将与 IDE 良好集成。例如，Clang 能够与主机 IDE 共享词法信息，以便进行语法高亮显示。
关于他们使用的优化技术，LLVM 团队中的一些人被禁止查看 GPL 3 代码。这使得尝试更新 LLVM 以匹配 GCC 功能变得很困难。
至于使其在 68k GCC 上工作，它可能已经完成了这种优化。GCC 4.5.x 完成的任何优化通常都在 GIMPLE 中间表示上完成，所以唯一的问题是后端在最终代码生成阶段没有生成经过微调的代码。
LLVM 将成为 AROS 编译器工具箱的一个很好的补充。我的梦想是拥有一个系统，在这个系统中，程序可以例如从运行在 x86 台式机上迁移到运行在基于 ARM 的智能手机上，再迁移到运行在 PPC A1/Pegasos 上。
LLVM 的 TableGen 实用程序，因此修改 x86 后端可能很困难。特别是由于他们对 AMD64 后端使用了一些与 x86 后端相同的模式。
我建议在 x86 中这样做的方法是使用 lib-call 自定义调用约定，该约定要求将相应的 lib-base 传递给 %EBX 中的函数，然后使用用于传递参数的任何其他寄存器使用固定偏移量索引到基索引中的跳转表。这样，寄存器分配器将自动处理 %EBX 的寄存器溢出，以便如果寄存器分配器可以分配一个寄存器来做到这一点，则可以将 %EBX 的先前值传递给另一个寄存器。
剩余的 调用约定 受支持。潜在问题包括
- LLVM 中间表示支持多个返回值，这与 C 不同，C 需要对堆栈进行特殊关注
- 中断将无法依赖 %EBX 保留用于系统使用，因为一组计算密集型的公式可能会导致寄存器分配器将 %EBX 溢出到堆栈，
并稍后检索它
- 如果我们不允许 %EBX 溢出到堆栈，那么我们将在 x86 后端做一些额外的工作以从寄存器选择中保留 %EBX。
它目前在内部使用 3 种调用约定，并允许使用几种系统特定的调用约定。
由于 %ebx 是一个堆栈指针，因此在离开函数或调用库中的外部函数时，您始终必须进行恢复。在分支中，这是通过在 gcc 中添加 -ffixed-ebx 选项来为伪交叉编译器完成的。
除了这些调用约定之外，还允许使用系统特定的约定。为此，我们需要一个库调用约定，以便在使用之前及时加载库的基指针。对纯重入基地址相对调用约定也是如此。
目前 %ebx 只是一个额外的堆栈指针，它与 i386 上的正常堆栈指针方向相反。它通常用于存储基指针。我实现了一个额外的堆栈指针，以便不必为每次函数调用添加基指针，也不必在调用库函数的存根代码中处理正常的堆栈。这样，您可以在库中函数的存根代码上将该堆栈中的基指针压入，而无需函数的源代码以特殊的 AROS_LH 宏开头。我将此用于调整后的 arosc.library，以便它不再需要 ETask。
另外，我需要知道这将如何影响 AROS 的 x86_64 版本。AMD64 ( ;) ) ABI 还需要讨论，但是是否有理由不遵循 i386 并以相同的方式使用 %ebx ？我对 AMD64 汇编不太熟悉。
看起来 有人 在捷克斯洛伐克开始了 M68K LLVM 移植工作。看看您是否可以将他们的 LLVM 代码更改提供给我？我希望支持 LLVM M68K，这将使我的工作变得容易很多。 学生 Vlamir 和 教授.
我一直在想，将基于 MMU 的 32 位沙箱模式合并到 AMD64 AROS 中有多难。这似乎是 PNaCl 在其用于便携式应用程序的 Chromium 浏览器插件中实现其 32 位基于 LLVM 的沙箱的方式。唯一的其他选择是必须为每个应用程序生成 2 个比特码，一个用于 32 位机器，另一个用于 64 位机器。我开始在 Sourceforge.net 上使用的 LLVM 包装器目前仅适用于 32 位应用程序，而且我只测试过它从一个 x86 操作系统到另一个 x86 操作系统的转换。