Page 131 - 《软件学报》2024年第6期
P. 131

谢汶兵 等: 二进制翻译技术综述                                                                2707


                 指令, 可以采用解释执行或者高级语言实现的函数模拟, 然而这种翻译方法的翻译效率差强人意.
                    不同平台的浮点和向量指令在精度处理、异常舍入等方面存在差异, 为了能精确模拟浮点结果, QEMU                                 采用
                 高级语言实现的      Helper 函数模拟, 并未考虑目标平台硬件特性, 翻译效率较低. Shi 等人             [26] 提出了充分利用目标平
                 台硬件浮点特性来简化浮点           Helper 函数模拟机制, 减少了不必要的边界判断, 但该方法对浮点异常处理不足.
                 Cota 等人  [171] 提出浮点运算部分采用硬件浮点指令实现, 异常处理部分则调用                 Helper 函数模拟实现. 该方法既保
                 证了二进制翻译对浮点指令模拟的正确性, 又充分利用了目标平台硬件特性. 针对                          Helper 函数引发的函数调用开
                 销问题, Wang  等人  [27] 提出将  Helper 函数全部内联到翻译代码中, 减少不必要的函数调用和上下文切换开销. Guo
                 等人  [172] 提出将浮点指令全部转换成      LLVM IR  表示, 不再依赖   Helper 函数, 然后利用   LLVM  编译器实现目标平台
                 硬件支持的浮点指令生成.
                    对于携带标志位指令的模拟是影响二进制翻译性能的又一个关键瓶颈. x86                        和  ARM  等架构采用专用标志位
                 处理条件转移指令, 并基于标志位实时反映处理器运行时的各种状态和运行结果. 而                          MIPS、RISC-V、Alpha 等并
                 没有标志位寄存器, 翻译时采用软件模拟标志位运算. 标志位的模拟不仅要完成标志寄存器逻辑功能, 还要实时更
                 新标志位的状态, 引入了大量的内存访问和额外计算开销. 文献                    [86] 统计发现模拟一条     ARM  条件转移指令平均
                 二进制翻译效率. 据我们调研所知, 目前针对此部分的研究较少.
                                                                                                      [1]
                 需要多达 16 条 RISC-V 指令模拟. 为了提高标志位的翻译效率并减少非必要的计算量, QEMU                         [13] 、FX!32 、
                 Harmonia [53] 等引入了延迟计算技术, 将标志位的计算向后拖延到执行阶段. 延迟计算有效地减少了代码计算量, 但
                 是部分标志位的定值并不会被后续指令使用, 此外, 标志位状态信息的存储也引入了额外开销. 为了进一步降低状
                 态标志位模拟开销, 文献       [173] 提出标志位的模式化翻译方法, 翻译时挖掘标志位定值与引用之间的语义关系, 选
                 择目标平台上具有相同语义功能的指令组合翻译标志位. 文献                    [86] 采用软硬协同的方式, 实现源平台与目标平台
                 标志位寄存器的一对一映射, 在不修改目标              ISA  和编程模型的前提下实现了标志位的设置和引用操作. Li 等人                [86]
                 扩展目标平台 ISA     中算术指令条件位的硬件功能和翻译器对应的                IR  表示, 实现源平台与目标平台标志位寄存器
                 的一对一映射.
                    不失一般性, 不同平台对基础函数库的接口设计是一致的. 因此, 将基础函数库的翻译直接转换为调用目标平
                 台的本地函数库可以避免大量翻译工作. Tan             等人  [174] 提出在翻译阶段结合可执行文件符号表和链接信息表, 将常
                 用库函数翻译转换为本地库函数调用, 实验表明对于部分测试课题的性能加速比达                            20.9  倍. 但其只实现了部分基
                 础库函数的本地化调用. 类似地, Box86/64       [60] 采用更加全面的函数库本地化, 将系统中常用的库函数全部实现了封
                 装和本地化调用. 函数库本地化在大量成熟的翻译系统设计中被广泛使用, 如                        Instrew [14,38] 和  FEX-Emu [39] 均采用了
                 函数库本地化设计思想. 然而, 在函数库本地化时涉及对被替换函数的符号解析和查询匹配, 减弱了库函数本地化
                 的优化效果. 傅立国等人       [175] 提出将函数库查询信息做静态预处理, 并使用散列函数优化查询过程, 降低了库函数
                 处理的查询开销.
                    除了上述优化, 研究发现在构建二进制翻译系统时, 其依赖的基础编译器优化能力也会影响翻译代码生成质
                 量. 本文基于   GCC  编译器分别在命令行选项“-O0”和“-O2”下构建           QEMU, 然后分别利用构建生成的          QEMU  完成
                 x86-64-to-ARM64  的二进制翻译, 测试集选用     SPEC2006  和  Windows 7  二进制应用. 表  8  列出了基于“-O2”选项相
                 比“-O0”选项构建的     QEMU  翻译器的翻译效率加速比, 测试结果表明采用更优的编译优化选项                      (-O2) 会显著影响


                                     表 8 QEMU   基于“-O0”和“-O2”选项构建时翻译性能加速比

                                       测试程序                          “-O2”/“-O0”选项加速比
                                     SPEC INT2006                          1.46
                                     SPEC FP2006                           7.18
                                      Windows 7                             2.5

                 4.4   软硬协同优化
                    采用软件模拟的二进制翻译方法较好屏蔽了硬件差异, 保证了源程序语义逻辑的正确翻译. 但是软件模拟的
   126   127   128   129   130   131   132   133   134   135   136