Z3：自定义理论扩展适合我的应用吗？

我对许多X86指令的行为进行了精确和有效的描述，这些行为适合于QF_ABV编码，并直接使用标准解算器进行解算，无需使用特殊的解算策略。我编写了一个SMT-LIB脚本，其界面与我的最终目标完美匹配：

X86State，一种记录排序，将x86机器状态寄存器和标志描述为位向量，将内存描述为数组。 X86Instr，一种记录排序，描述x86指令枚举助记符，操作数作为一个类似于ML的判别并集，描述寄存器、内存表达式等。 函数x86 translate接受X86State和X86Instr，并返回新的X86State。它解码X86Instr并根据给定X86Instr对输入X86State的符号效果生成新的X86State。 它非常适合原型设计：用户可以轻松直接地编写x86。在简化使用库构建的公式后，所有函数和无关数据类型都将被消除，留下QF_ABV表达式。我希望用户可以简单地设置逻辑QF_ABV并包含我的脚本，不管是SMT-LIB标准还是Z3支持都不包含

不幸的是，通过定义函数和类型，脚本需要诸如未解释函数之类的理论，因此由于类型的原因，需要QF_ABV甚至QF_AUFBV之外的逻辑。我使用SMT解算器的经验表明，应指定最低可接受逻辑以获得最佳解算时间。此外，还不清楚我是否可以在编程环境中重用我的SMT-LIB脚本，如OCaml、Python、C等。最后，由于缺少高阶函数，并且缺少对PAR的访问导致代码复制，所以脚本有点冗长。

---

因此，尽管我已经完成了技术目标，但我认为SMT-LIB可能是错误的方法。是否有更自然的途径与Z3交互以实现我的x86指令描述/QF_ABV转换方案？SMT-LIB脚本在这些途径中是否可以重用？例如，您可以构建定制的OCaml顶层，即带有脚本的解释器。像那样的事情可能会很好。或者我必须用另一种语言重新实现功能，在一个通过理论扩展C DLL与Z3交互的程序中？这里最好的选择是什么？

嗯，我不认为人们会手工编写.smt2文件。这些通常由一些程序自动生成。 我发现Z3 Python接口相当不错，所以我想您可以试试。但是你可以用任何语言编写一个简单的.smt2转储程序

顺便问一下，您是否计划发布您为X86编写的规范？我真的很感兴趣