时间:2024-07-28
蔡慧玲 ,刘博
多机器人系统与传统的单一机器人相比有着诸多优点如[1]:机器人间可以并行作业提高生产效率;可以相互协作完成复杂任务;部分机器人失效不会影响整体作业提高了可靠性。但是异构多中机器人系统,由于来自不同生产商或不同时期产品,各自平台可能不一致,存在异构性,这给代码的移植带来了困难。虚拟机作为软硬件之间的中间层,使软件的二进制代码不再直接运行在物理机器之上,通过代码解释或者二进制翻译的方法,转换为目标处理器的可执行代码,来达到实现支持多指令集的目的。
在动态二进制翻译中,翻译是即时进行的,对效率有很高的要求。一般的动态二进制翻译,都采用基于软件的方法实现,即翻译-执行-再翻译-再执行的软件执行主流程。所以在这样的 ISA兼容过程种,解释执行和翻译代码的时空开销较大,用特殊的硬件资源来加速动态二进制翻译是一个直接的选择。为此,本文提出了一种基于软硬件协同设计的动态二进制翻译实现方法。
典型的动态二进制翻译的工作流程为:二进制翻译单元翻译以源机器程序计数器(Source Program Counter,SPC)为输入,首先在目标代码块缓存(Target Code Cache, TCache)中寻找是否有已翻译过的代码块对应该SPC值。如果命中(Hit)即表明该基本快已经被翻译,则跳转至该目标代码直接执行;如果缺失(Miss),则开始翻译工作。翻译工作包括构造代码块,翻译代码块生成目标代码块(Target Code Block,TBlock),最后存入TCache空间,如图1所示。
二进制代码基本块(Basic Block)是动态二进制翻译系统中,进行代码翻译的基本单位,即一段翻译后代码片段(Translated Code Segment,TCS)所对应的源结构指令片段。动态二进制翻译中,执行一个基本块所用的时间开销分析可以用等式(1)表示。其中 linked代表基本块链接的比率,lookup time是查找 SPC-TPC map表的时间。
图1 动态二进制翻译工作流程图
通过对进程级虚拟机CrossBit[2]的SPEC2000测试数据分析,存在如下影响性能的主要因素:
⑴ TCache的管理单元部分。翻译好的目标指令存储在二进制翻译的用户空间TCache中,下一个要执行的基本块的是否已经翻译完成,必须由查看 SPC(Source Program Counter)到TPC(Target Program Counter)的映射表获得,由于一个程序中基本块数量的庞大,映射查询操作成为频繁事件,那么映射查询时间(Lookup Time)相应增大[3]。将TCache的管理和查找由硬件实现,以指令的形式实现查找操作,这样将lookup 开销降到最低。同时,采用硬件实现查找大大减少了 lookup时间。在查找的过程中也可以收集执行信息,以利于将来profiling优化程序中的热路径分析[4]。
⑵ 执行单元和二进制翻译单元以及TCache管理单元的上下文信息缓存以及恢复(context switch time)。当处理器从目标代码的执行状态,切换到对源二进制代码的翻译状态时,需要做上下文的保存和恢复,在翻译执行过程对每一个基本块都需要这样做,无法避免频繁切换带来的高开销。那么,在本文的设计中将动态二进制翻译单元独立出来,从原来的解释-执行-再翻译-再执行的主流程中抽离出来,由独立的硬件单元实现,从而避免频繁切换带来的性能开销。
⑶ 翻译单元的构造对性能的影响。动态二进制翻译系统的总的执行时间,由指令解释执行时间、代码翻译开销、翻译后代码执行时间以及profile开销几部分组成:
其中Iinterp为系统解释执行的源结构指令数;Tinterp为解释执行一条源结构指令的平均时间;Itrans为翻译的源结构指令数;Ttrans为翻译一条指令的平均时间:Vcmt和Vcnl分别为提交和取消的翻译后代码VLIW条数;Tvliw为条VLIW的平均执行时间;Nprof为profile代码执行次数;Tprof为profile代码的平均执行时间。构造高效的硬件翻译对系统的系能有着重要影响。硬件支持的翻译单元降低了软件的开销,提高系统实时性。
实现兼容性和高性能的目标,要求将源体系结构的资源高效地映射到目标体系结构中。这涉及到硬件支持单元与主处理器核心的协作,其设计关键在于合适地划分软硬件界面,在低硬件复杂性下实现动态二进制翻译系统整体的高性能。基于上述性能模型中的分析,我们提出基于硬件支持的二进制翻译系统。
系统的总体结构分为3部分:软件层包括x86可执行文件的加载器和虚拟机IP核驱动程序以及Linux操作系统,硬件部分包括PowerPC处理器、内存和虚拟机IP核。其中虚拟机的IP核主要由两部分组成:二进制翻译器和TCache管理器。软件与硬件之间的通信问题由共享存储的方式解决。系统结构如图2所示;
图2 软硬件协同动态二进制翻译系统结构图
加载器负责源机器程序映像的加载工作。主要工作包括可执行文件各个段的提取,并映射程序段和代码段到进程地址空间。加载成功后,源机器程序的数据以及运行时所需要的栈和堆空间,将位于 Loader进程地址空间的适当位置,如图3所示。整个目标处理器的代码都在Loader的进程地址空间执行。
图3 系统运行时地址空间布局
Loader得到代码段的入口地址后(SPC),就跳转到Stub Code,以SPC查找TPC,如果命中就跳转到TPC处执行,不命中则循环检测,这时会启动二进制翻译器翻译该基本块。这样避免了运行和翻译环境的切换(context switch)。这种查找并不是每次必须的,当实现了基本块的链接之后,就不必跳转到Stub Code查找,而是直接跳转到下一个基本块去执行。
动态二进制翻译是进程级的应用程序依附于操作系统之上。执行引擎指挥翻译与执行构成中所有的工作。虚拟机IP核的驱动程序主要工作是负责主处理器和二进制翻译单元的通信与同步,包括源机器代码的加载和目标代码的拷贝、中断异常处理等。在软硬件的同步与通信上,我们采用共享存储的方式。同时,为避免执行单元与翻译单元对存储代码的读写冲突,在系统结构里增加了快速查询表。该查询表以基本块地址指针和是否被翻译的标识符为查询信息元,避免软硬件对存储代码的读写冲突。为了更加快速和方便的访问硬件翻译单元的内存空间,采用内存映射的方法,将翻译器的物理地址映射,到操作系统的一段虚拟地址空间,这样就可以直接访问硬件单元的寄存器。
硬件翻译单元主要具备动态二进制翻译和TCache管理功能。由于本设计向前兼容的是x86体系结构,x86指令集是典型的CISC架构。其指令不仅种类繁多,而且编码格式复杂,指令长度变化很大,所以二进制翻译单元采用状态机的设计。总体状态转换图如图4所示。
Wait状态:系统reset后或者一个基本块翻译结束后进入的状态,根据must_translate标志判断是否进入开始翻译基本块阶段。
Start状态:判断指令是否存在前缀,是单字节操作码指令还是双字节操作码指令。
Opcode1状态:单字节操作码指令根据指令码可能进入译码状态(如操作数都是寄存器的指令)、取立即数状态、MOD_RM状态。
Opcode2状态:和opcode1的状态转换类似。
Imm状态:对于存在立即数的指令,需要生成PowerPC指令以装载立即数进临时寄存器。
MOD_RM状态:根据寻址方式字段判断是否是register方式,是否带SIB,是否有immediate进入decode状态、SIB、Imm状态。
SIB状态:比例变址基址域的地址计算。
Disp状态:带偏移的地址处理。
Semantic decode: 语义译码阶段,这时所有的操作数在寄存器中或者是立即数。根据操作码语义进行译码生成PowerPC指令。
Block_wrap: 一个基本块的结束,主要进行基本块在Tcache中存放地址的计算,更新查看TPC映射表,下一个基本块的地址等。
总的来说,指令翻译分为两个阶段:寻址操作数翻译阶段和语义翻译阶段。第一个阶段主要完成x86复杂的操作数寻址,将操作数放置于临时寄存器中(图4中的SIB,Disp,Imm状态)。第二个阶段主要是指令本身的语义翻译,这时所有的操作数都是寄存器或者立即数(图4中的Semantic Decode状态)。
图4 翻译器状态转移图
本文设计的基于软硬件协同设计的动态二进制翻译系统,成功实现了x86 ELF可执行文件的加载、翻译以及执行。翻译系统的源结构,为IA-32结构的整数指令部分,目标体系结构为IBM PowerPC结构。
在系统成功加入硬件支持后,我们对典型二进制翻译系统性能瓶颈部分,进行了详细分析与性能比较。测试程序为典型的x86可执行文件,包含了计算,中断和系统调用。
图5 性能瓶颈部分对比评测
图5表示的是进程级虚拟机的原瓶颈部分和改进后,软硬件协同设计翻译系统的性能比较。从表中数据可以发现硬件支持的动态二进制翻译系统,TCache的查找时间和基本块的翻译时间,都得到很好的改善。同时,程序基本块命中和缺失情况下的软硬件协同设计翻译系统和基于软件二进制翻译系统的执行时间的比较,除了性能提高以外,前者在命中和缺失两种情况下表现平稳,在缺失的情况下性能波动不大,而基于软件的二进制翻译系统的缺失惩罚比较大,影响程序的实时性和启动时间。
随着技术的进步,多机器人系统将更多地出现在人们的生活中,它们在改善人类工作和生活的同时,由于自身平台异构性,也给开发者带来了兼容性方面的问题。本文讨论了一种基于软硬件协同设计的动态二进制翻译的设计与实现,提出了通过硬件加速技术来消除性能瓶颈。实验数据表明,硬件支持单元的集成,有效地改善了二进制翻译的性能。将其用于多机器人系统,可以高效使用现有代码,减少移植和新开发带来的工作量。
[1] 谭民,范永,徐国华.多机器人群体协作与控制的研究[J] .机器人, 2001,(2):178-182.
[2] Bao Yuncheng. Building Process Virtual Machine via Dynamic Binary Translation [D] . Shanghai Jiao Tong University, 2006.
[3] Baker A J, Kent K B. Design & Implementation of the Interface of a Hardware/Software Co-Designed Virtual Machine. [C] //PACRIM 2007: 109-112.
[4] Mishra C, Volkovs M.ConEx: a system for monitoring queries[C] // SIGMOD Conference 2007: 1076-1078.
我们致力于保护作者版权,注重分享,被刊用文章因无法核实真实出处,未能及时与作者取得联系,或有版权异议的,请联系管理员,我们会立即处理! 部分文章是来自各大过期杂志,内容仅供学习参考,不准确地方联系删除处理!