1994 年，Philippe Codognet 与 Daniel Diaz 在 ACM SIGPLAN Notices 上发表了题为《A piggy-back compiler for Prolog》的论文，提出了一种将 Prolog 编译为 C 代码的创新方法。这一技术路径不仅为后续 GNU Prolog 的 C 后端奠定了基础，更开创了将逻辑编程语言作为嵌入式领域特定语言集成到系统编程语言中的先河。与 λProlog 所代表的高阶逻辑编程方向不同，piggy-back 编译器专注于编译器层面的实现，通过借力成熟的 C 编译器工具链来实现 Prolog 的高效执行。
piggy-back 编译器的核心思想在于 “骑乘” 现有的 C 编译器来完成目标代码生成。其工作流程首先将 Prolog 源代码转换为中间表示形式，随后将中间表示翻译为 C 代码，最后利用标准 C 编译器进行编译和优化。这种两步翻译的策略使得 Prolog 能够充分利用 C 语言编译器的优化 passes、寄存器分配算法以及平台特定的代码生成能力，从而获得接近原生代码的执行效率。与纯粹的解释执行或简单的 FFI 绑定不同，piggy-back 编译器在编译期完成了逻辑程序到系统级语言的转换，实现了逻辑编程与系统编程语言在编译器层面的深度融合。
从混合开发范式的角度来看，piggy-back 编译器为开发者提供了一种在 C 项目中嵌入逻辑编程能力的可行路径。在实际工程中，某些问题域天然适合用逻辑编程的搜索与回溯机制来表达，例如约束求解、规则引擎和自动推理等场景。通过将 Prolog 编译为 C 代码，开发者可以在保持 C 语言对硬件的直接控制能力的同时，将复杂的逻辑推理任务交给 Prolog 引擎处理。这种分工模式既保留了系统编程语言对性能和内存管理的精细控制，又借助逻辑编程的表达力来简化复杂业务规则的实现。
在嵌入式 Prolog 的实现中，Amzi! Prolog + Logic Server 提供了另一种集成思路。作为一款可嵌入、可扩展的 Prolog 实现，Amzi! 通过其 Logic Server API 提供了双向调用机制，支持从 C、C++、Java、Delphi、.NET 等多种宿主语言调用 Prolog predicates，以及从 Prolog 调用宿主语言函数。Amzi! 采用虚拟机架构来实现二进制代码的跨平台独立性，其设计哲学强调与宿主应用的紧密集成，而非单纯的编译器优化。这种运行时集成方式与 piggy-back 编译器的编译时策略形成了互补，开发者可以根据具体场景选择更适合的集成方案。
从编译器设计的角度审视，piggy-back 编译器的技术价值体现在多个层面。首先，它证明了通过中间表示层将高级语言翻译为 C 代码的可行性，为后续多种语言的编译器实现提供了参考范式。其次，借力成熟 C 编译器的策略显著降低了开发成本，使得 Prolog 实现者能够专注于前端优化而将后端代码生成交给专业工具完成。最后，这种设计也为后来的嵌入式 DSL 研究奠定了基础，展示了如何利用宿主语言的工具链来实现领域特定语言的编译目标。
在实际的混合开发实践中，开发者需要考虑几个关键参数以确保集成方案的可行性。编译目标选择方面，若追求执行效率优先，可采用 piggy-back 编译策略将 Prolog 代码静态编译为 C 后再链接；若追求快速迭代和动态加载，则可考虑 Amzi! 等运行时嵌入方案。内存管理方面，由于 Prolog 的垃圾回收机制与 C 的手动管理风格不同，需要在边界处设计合理的内存分配策略，建议为 Prolog 引擎预留独立的内存池并设置合理的栈空间阈值。调用开销方面，跨语言函数调用存在一定的性能损耗，对于高频调用场景应尽量将逻辑封装在单一语言内部。此外，错误处理机制的统一设计也至关重要，应建立一致的异常传播路径以便于调试和维护。
综合来看，1994 年的 piggy-back 编译器工作为 Prolog 作为嵌入式 DSL 在 C 中的应用开辟了编译器层面的技术路径。它与后续出现的嵌入式 Prolog 运行时方案共同构成了混合逻辑编程与系统编程的开发范式，为处理需要复杂推理能力的应用场景提供了实用的工程化选择。
资料来源：Codognet & Diaz (1994), "A piggy-back compiler for Prolog", ACM SIGPLAN Notices / WLP'94; Amzi! Prolog + Logic Server 产品文档