asmjit是轻量jit表达式引擎的最佳选择：单文件集成、毫秒级编译、支持多平台，通过compiler自动管理寄存器与栈帧，结合context传入c函数指针实现安全调用。
为什么不用 LLVM 或 libjit？
LLVM 太重，编译依赖多、链接体积大、初始化慢，嵌入到配置热更新或规则引擎里会拖累启动；libjit 已停止维护，ABI 不稳定，x86_64 上生成的代码在 macos ARM64 下直接失效。真正轻量的 JIT 表达式引擎，核心诉求是：单文件集成、毫秒级编译延迟、支持 double/bool/int 基本类型、能调用 C 函数指针——不是做通用编译器，而是让 a * sin(b) + c > 0 这类字符串在运行时变成可执行机器码。
asmjit::JitRuntime 怎么最小化接入？
AsmJit 是目前最合适的底层选择：头文件为主、无外部依赖、支持 x86/x64/ARM64、API 清晰。但直接用它写表达式编译器容易掉进“手写寄存器分配”的坑里。正确做法是只用它做 CodeHolder + Runtime 管理，把 AST 到汇编的映射交给中间层。
- 不要手动 emit
mov rax, [rbp+8]——用 AsmJit 的Compiler（非CodeEmitter）自动管理栈帧和寄存器 - 每个表达式编译为独立函数，签名固定为
double(double*, void*)，第二个参数传入自定义 context（比如含函数表的 Struct） - 务必调用
runtime.add()后立刻runtime.release()对应的CodeHolder，否则内存泄漏（AsmJit 不自动回收未 add 的 code） - windows 上需显式调用
VirtualProtect设置页可执行（runtime.getCodeInfo().isExecutable()返回 false 时必须处理）
如何安全地把 sin/log 这类 C 函数注入 JIT？
不能在 JIT 代码里硬编码 call sin，因为 sin 地址在 ASLR 下每次进程启动都变，且跨平台符号名不一致（macOS 是 _sin）。必须通过间接调用 + context 传入函数指针。
- 定义 context 结构体：
struct ExprContext { double (*sin_fn)(double); int (*strcmp_fn)(const char*, const char*); }; - JIT 编译时，对每个函数调用生成类似
mov rax, [rdi + 0]（rdi 是 context 指针，偏移按字段顺序算），再call rax - 确保 context 生命周期长于 JIT 函数——不能栈上分配后返回指针，得 heap 分配或 Static 存储
- 避免函数指针被编译器优化成 inline（GCC/Clang 加
__attribute__((noinline))，MSVC 加__declspec(noinline)）
表达式 AST 到 JIT 的关键转换点
真正卡住多数人的不是汇编生成，而是类型推导和短路逻辑落地。比如 a && b || c，c++ 语义要求 && 左操作数为 false 时跳过右操作数，这必须编译为条件跳转，不能简单转成 and/or 位运算。
立即学习“C++免费学习笔记（深入）”；
- 所有二元操作符优先级必须在 parser 阶段建树完成，JIT 层只遍历 AST，不重新解析
- 布尔表达式（
==、&&、||）统一返回int（0 或 1），由调用方决定是否转 double - 访问数组或对象字段（如
user.age）不能硬编码 offset，必须通过 context 提供的 getter 函数回调，保持引擎与数据模型解耦 - 浮点比较（
a == b）默认不做 epsilon 容差——这是业务逻辑，JIT 层只生成严格 bit-equal 比较，容差由上层函数（如传入的eq_fn）实现
最难调试的是寄存器溢出和栈对齐：AsmJit 的 Compiler 在函数参数超过 4 个时可能 misalign rsp，导致 sqrt 等 SIMD 函数崩溃。真遇到 segfault，先检查 compiler.addFunc(FuncSignatureT<double double void>())</double> 的签名是否与实际调用完全一致，一个字节错都会让整个栈帧错位。