我很想听听人们对在FPGA上实现编译器有多难的看法。例如，这可能只是一个编译器后端，LLVM，实现只需要LLVM IR和输出机器代码。
这样做的目的是允许 - 可以这么说 - 实时执行源代码（或中间代表代码），就像你：
对于给定的系统，FPGA的或多或少静态部分可以是LLVM后端，即。决定输出什么类型的机器代码的部分，例如带有SSE4的x86-64。或带有NEON和VFP指令的ARM Thumb-2。除非您的系统具有多个CPU，否则这将保持不变。这不应该是完全静态的，因此不能在硬件中实现，因为编译器的优化是不断进行的，并且需要不时地更新。 更频繁变化的FPGA部分将是前端，即从给定语言生成LLVM IR的部分：C，C ++，Vala等。
这个系统的巧妙之处在于代码总是针对手头系统中的CPU进行优化。在目前的情况下，很少有构建利用CPU中的所有额外功能：SSE，AVX，3DNow！，Neon，VFP。使用这种（完全假设的）方法，可以通过实时编译特定体系结构并在之后立即执行生成的指令来利用CPU的全部潜力。 这对于基于ARM的系统尤其有用，因为我们需要从CPU中挤出所有的汁液，而CPU本身在编译时非常慢。
我知道gcc可以设置为使用线程，并且，我假设并行化编译器会相对容易。即，只是并行编译所有源文件。
我们也可以抛弃前端 - 编译器特定于编程语言的部分 - 只是将程序作为LLVM IR之类的中间表示代码进行分发。
这是否可行？
答案 0 :(得分：2)
我不会打扰。我将FPGA配置为LLVM IR VM，只运行代码，将控制硬件委托给CPU。
答案 1 :(得分：1)
编译的某些部分非常容易以非线程方式并行化。例如，字符串键控字典非常常见，因此内容可寻址内存可以提供显着的优化。
然而，对于编译的某些方面，FPGA的表现非常糟糕。例如，重载分辨率必须考虑依赖于参数的查找，用户定义的转换，模板等。通过流水线操作和使用FPGA和CPU的资源，您将获得最佳性能。例如，让FPGA了解源代码并创建一个令牌流，其中所有标识符都被符号表索引替换，而CPU则运行以后的编译步骤（例如内联和循环优化）。
当然，您已经指出，如果代码可以预处理并以p代码格式分发，则这对于每台机器的优化没有多大帮助。可能会在开发期间制作一个很好的编译加速器。
答案 2 :(得分：1)
前段时间我也有同样的想法。
鉴于适当的合成技术，在FPGA上实现这样一个复杂的程序是可能的。使用行为综合（又称C到HDL synthis）使其可行。
有趣的是，如果编译器的输出也是HDL，那么可以设想引导行为合成器（即使其自身合成），这通常是编译器的重要验证步骤。
答案 3 :(得分：0)
Alan Kay给出了一个很酷的talk来探讨这个想法。他的团队构建了一个操作系统，其目标是每个域（例如图形，网络）都是用超高级语言编写的，尽可能接近理论。
他们最初想在硬件（FPGA或ASIC）中为所有这些语言制作口译员，但他们受到商品笔记本电脑演示的诱惑力。凯表示，仅仅在图形位中就有“几个”博士论文的价值。所以“可行”是一个问题，你可以在这个问题上投入多少时间和才能。
这次演讲让我真正批评了在硬件和软件中使用通用工具所涉及的权衡。