加载失败
这篇讨论围绕 Elevator（一个把 x86-64 二进制静态翻译成 AArch64/ARM64 可执行文件的项目）展开，它不依赖运行时 JIT，而是通过 superset disassembly 和超集 CFG 预先生成所有可能路径。评论里把它和 QEMU user-mode JIT（QEMU 的用户态动态翻译）、Box64（x86-64 到 ARM 的兼容层）以及 Rosetta（Apple 的 x86-64→ARM 动态翻译层）对比，重点不是“能不能跑”，而是“能否把输出变成可签名、可认证、行为确定的二进制”。因为 x86 指令边界和代码/数据界限天然模糊，这类工具必须处理间接跳转、回调和异常等复杂控制流，否则就会在体积和兼容性上迅速膨胀。讨论也反复强调它更适合受监管、要求可复现构建的场景，而不是替代完整的桌面兼容层。
不少评论把核心价值放在结果确定、可签名，而不是极限性能上。对航空、医疗、其他受监管行业来说，运行时 JIT 往往不被允许，交付的代码必须和认证时保持一致，甚至还要把 cryptographic hash 交给监管方。静态翻译如果能产出固定二进制，就能直接嵌入这类合规流程。也有人顺带指出，生成式代码在这些领域本来就常见，关键是最终交付物要稳定、可审计。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
很多人承认 50x 的 .text 膨胀非常夸张，但也认为在对比 QEMU user-mode JIT 时，换来的速度仍可能值得。评论里给出的数字大约是 4.75x 的运行时加速、7x 的执行指令数增长，以及 50x 的二进制体积增长；相比之下，它比 QEMU 快，但还明显落后 Rosetta。有人解释说 QEMU 的 TCG（Tiny Code Generator）本来就是面向多架构的通用设计，无法像专门针对 x86→AArch64 的翻译器那样做硬分配寄存器之类的定制优化。也有人担心巨大的代码体积会伤害 cache locality，不过支持者认为可通过 link-time code reordering 缓解一部分热路径问题。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
对于 indirect jump，讨论里给出的办法很直接：先把原始地址到翻译后代码块的对应关系放进查找表，运行时再按目标地址查表跳转。这样比 direct branch 慢一些，但间接跳转本来就比直跳贵，通常也不在最热的循环里。有人补充说，真正需要关注的是解释器式的 dispatch 循环，因为它们会频繁依赖这种间接分派。整体思路是先把所有可能落点都准备好，再把不确定性推迟到运行时解决。
项目明确不支持 self-modifying code 和 JIT-compiled code，因为那会和 fully static 的目标直接冲突。评论解释说，x86 没有严格的代码/数据分离，指令边界也不对齐，静态分析时只能把每个可执行字节偏移都当成潜在起点，于是才有 superset disassembly 和 superset CFG 这种做法。代价是会生成大量候选译码，再把会走向异常终止的路径剪掉，所以体积会迅速膨胀。大家也因此把它归类为适合协作型 binary，而不是对抗性代码、手写 asm、复杂异常处理、线程和动态生成代码的万能方案。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11]
当有人问能不能直接跑 Slack on Asahi，答案基本是否定的：Slack 是 Electron 应用，内部还带 Chromium、Node 和 V8，远超当前支持范围。评论列出的限制包括仅支持 single-thread binaries、没有 exception handling/unwinding、还有一些 x64 extensions 不支持。也有人指出，某些固定字节序列的小片段看起来像 `mov eax, 42; ret` 这种简单函数，但 runtime code generation 和大型桌面框架才是真正难点。它更像是针对一类明确边界内的 binary compatibility tool，而不是完整 OS 兼容层。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
superset CFG（超集控制流图）: 把每个可执行字节偏移都当成潜在指令起点来构造的控制流图超集，用来覆盖 x86 指令边界不确定性。
TCG（Tiny Code Generator）: QEMU 用来把 guest 指令转成中间表示并翻译到 host 的通用翻译后端。
W^X: 一种内存安全策略，要求同一页不能同时 writable 和 executable，用来限制 self-modifying code 和 JIT。
TSO（Total Store Order）: x86 的内存一致性模型；讨论中用来解释 Rosetta 和 ARM 兼容语义的关系。