c - 在正常情况下，未注册模式要求是否会阻止 Haskell 的基本 FFI 示例？

Question

来自Haskell Wiki page about calling Haskell function from C ，我正在尝试重现一个很好的简短示例，它归结为编译一些使用 C FFI 和命令行选项的 Haskell 代码，例如:

ghc -c -O Safe.hs

需要注意的一点是，在 Haskell Wiki 页面中，使用的编译器选项实际上是 -c(小写)，这不会生成中间 C 代码，所以这可能是一个拼写错误.

但是，正如我在尝试使用 -C 选项(记录为发出中间 C 代码的选项)进行编译时发现的那样，除非您在“未注册模式”下构建 GHC，否则这是不可用的基本上放弃了 GHC 的 native 代码生成器，只留下一个非常基本的 C 代码生成器(用于这些 FFI 示例的)和高度优化的基于 LLVM 的代码生成器。

事实上，from some documentation about GHC ，它建议您只能在未注册模式下使用-C选项。

为了生成中间 C 代码(通过 -C 选项)，您必须在未注册模式下构建 GHC 是真的吗？

如果这是真的，这是否意味着您几乎在任何情况下都不能按照这些说明从 C 代码调用 Haskell 代码(因为在未注册模式下构建通常是不可取的并且非常罕见)？

在我的例子中，我实际上有一个 Python 库和一些项目限制，这些限制意味着代码必须可以从 Python 调用，但是通过使用 Haskell 编写大量代码并使用 Haskell 函数可以大大受益。

我的目标是为 Python 创建一个扩展模块，使用带有 C 源代码的 Cython 可以很容易地做到这一点。因此，如果我可以创建 Haskell-from-C 源代码并将其编译为一个库，那么从 Python 调用它将会非常容易。然后我可以担心如何自动生成包装器代码。

但是如果它需要这种非常专业的构建 GHC 的方法，那么它对以后需要使用它的任何人都没有用，因为他们可能没有那种专门的构建并且不想大惊小怪.

这样一个简单的 FFI 功能(C 代码生成部分)似乎应该在任何 Haskell 编译器的最普通版本中“正常工作”，至少对我来说是这样。

Answer 1

如 Wiki 页面所述，您不需要未注册的 GHC 即可将 Haskell 函数导出到 C。这里有很多具体问题，我会一一解答。

From the Haskell Wiki page about calling Haskell function from C, there is a nice short example that I am trying to reproduce, which boils down to compiling some Haskell code that uses the C FFI with command line options such as:

 ghc -c -O Safe.hs

One point of note is that in the Haskell Wiki page, the compiler option used is actually -c (lower case) and this does not generate the intermediate C code, so it is likely a typo.

这不是打字错误。 -c 表示“编译为对象 (.o) 文件”，而不是默认的“编译为可执行文件”。 (选项名称与 C 编译器中相同选项的名称匹配，这就是它没有特别意义的原因。)

However, as I discovered when trying to compile with the -C option (the option that is documented as emitting intermediate C code), this is unavailable unless you build GHC in "unregisterised mode" which essentially drops GHC's native code generator and leaves only a very basic C code generator (what is used for these FFI examples) and the more highly optimized LLVM-based code generator.

In fact, from some documentation about GHC, it suggests that you can only use the -C option in unregisterised mode.

Is it true that you must build GHC in unregisterised mode in order to generate intermediate C code (via the -C option)?

是的，因为只有未注册的编译器才能通过中间 C 代码进行编译。注册编译器(因此得名)使用的 GHC 调用约定(将各种全局变量固定到寄存器)根本无法用 C 语言表达。并且，特定的 GHC 构建是生成注册代码还是未注册代码是在该 GHC 构建的编译时做出的决定。

If this is true, doesn't it imply that you can't follow these instructions to call Haskell code from C code in almost any situation (since building in unregisterised mode is generally undesirable and very uncommon)?

不，因为您也可以从 C 代码调用由注册编译器构建的 Haskell 代码。 C 的一个很好的特性是它有一个相对标准的(每个平台)ABI，因此任何语言的编译器都可以生成与 C 目标文件二进制兼容的目标文件，而根本不需要调用主机 C 编译器。

In my case, I have actually a Python library and some project constraints that imply the code must be callable from Python, but which can benefit greatly from writing a lot of it in Haskell and using Haskell functions.

My goal is to create an extension module for Python, which is very easy to do using Cython with C source. So if I can create the Haskell-from-C source and compile it to a library, it will be pretty easy to call from Python. Then I can worry about how to generate that wrapper code automatically.

But if it requires this very specialized way of building GHC, it won't be useful to anyone who needs to work with it later, because they probably won't have that specialized build and won't want to fuss with it.

Such a simple FFI capability (the C code generation part) seems like something that should "just work" in the most vanilla of builds of any Haskell compiler, at least to me.

是的，它只适用于任何 GHC 版本。它实际上并没有作为中间形式通过 C； GHC 的输出是一个目标文件。