一种应用于Android系统x86架构上的ARM指令集转换方法

摘要

一种应用于Android系统x86架构上的ARM指令集转换方法，所述方法包括步骤：Android系统开机通过binfmt_misc向内核注册所述ARM二进制文件的打开方式；启动Android应用时识别所述ARM二进制文件；通过所述已注册打开方式加载ARM二进制文件；所述加载过程在Android系统中创建虚拟执行空间；所述虚拟执行空间中构建虚拟ARM架构CPU；所述ARM二进制文件运行在所述虚拟ARM架构CPU上；所述虚拟ARM架构CPU遵循预设转换规则执行转换得到本地代码；将所述本地代码推送到本地CPU上执行；本地CPU上执行完回传数据结果给Android应用。本发明的有益效果是：扩展Linux系统x86架构上的应用生态，给用户带来丰富的内容体验和更加智能的人机交互体验的同时，还能保证最低程度的减少对CPU的性能损耗，避免大型应用运行时出现卡顿。

说明书

技术领域

本发明属于Android系统技术领域，具体涉及一种应用于Android系统x86架构上的ARM指令集转换方法。

背景技术

近年来，随着Android用户的增长，以及Android软硬件产品的成熟和发展，Android应用生态呈现出爆发式发展，在很多领域都已经超过Windows和iOS，成为目前使用最广泛的应用生态。Android基于Linux内核发展而来，是目前移动终端市场中市场份额最高的Linux类操作系统，在移动终端领域具有极好的生态环境；Windows系统占据着PC市场的最大份额，其作为美国闭源操作系统，在信息网络安全方面存在巨大安全隐患；而Linux操作系统，其作为Android的前身，由于开发人员数目和市场份额的限制，发展较为缓慢，生态环境长期处于不良状态，一直不见起色。随着信息技术的飞速发展，国家对信息安全的重视程度日益提升，国内基于开源Linux操作系统的自主操作系统日益发展壮大，但Linux操作系统生态应用的严重缺乏仍旧是困扰Linux操作系统真正推向市场的一大痛点。

要解决Linux操作系统的生态问题，必须解决用户数不足和平台应用软件数不足这两个关键点。Android在移动终端领域具有广泛的用户群，并且具有成熟的开发平台和应用软件群体，对于解决Linux操作系统目前的窘境具有一定的参考价值。

由于Android操作系统基于Linux内核发展而来，其针对移动终端设备的特点在用户空间做了大幅的改进和增强，所以给Linux操作系统兼容Android应用提供了极大的可能性和便利，使得移动端的丰富应用很有可能成功运行在PC端。近年来，Android应用生态在Linux操作系统上的兼容支持成为了研究热点，国内外有许多研究人员尝试将Android运行环境迁移到Linux类计算机平台以实现Android应用生态在Linux操作系统上兼容支持的效果，各种兼容技术衍生而出，其中就包括Google的ARC(App Runtime for Chrome)技术，虚拟机和模拟器技术、Anbox(Android in a Box)项目等，这些技术将PC端和移动端进行融合，成功将Android应用生态迁移到Linux上来，极大地推动了Linux应用生态的发展，很大程度上弥补了Linux应用缺乏的诟病，方便了Linux操作系统用户的日常办公、娱乐等需求，也加快了Linux操作系统走向消费市场的步伐，但它们都还存在着用户无法忽视的体验问题，包括稳定性、易用性、功能完备性等，导致这块技术领域没有显著的提升。

当前，ARM架构的Linux系统已经做到了对Android热门应用的兼容，因为Android应用本身是用ARM架构编译打包的，可以不需要考虑指令集转换就直接安装运行，但很大一部分用户在PC机上的选择依然会倾向于x86架构的CPU。架构的不同，就带来了指令集不通，对推进原定的应用生态发展形成了极大阻碍，所以在x86架构上兼容Android已有的ARM应用或者说ARM二进制，是一个非常值得研究和突破的技术工作。

在Android系统中，java代码运行在虚拟机上，不需要进行二进制转换，但库文件的运行需要有对应架构环境的支持，即前面说的架构不同，指令集不通，x86架构无法直接运行ARM架构的二进制文件。现在大部分Android应用没有打包x86的库文件，而只打包ARM的库文件，所以需要二进制转换。在x86平台兼容ARM二进制的已有技术如houdini，是intel为了让ARM应用能运行在x86架构上而研发的,其原理是当Dalvik VM加载native lib失败时，程序流会再次尝试用libhoudini中的my_dlopen打开，该方式类似于中的user mode，通过虚拟一个ARM的CPU(包含指令集和寄存器)来执行ARM的二进制指令。目前houdini技术不开源，且只支持大部分Android的ARM应用和部分Android版本，特别是在Android10和Android11上，目前依靠houdini技术是完全行不通的。

发明内容

为解决上述问题，本发明提供了一种应用于Android系统x86架构上的ARM指令集转换方法，所述方法包括步骤：

Android系统开机通过binfmt_misc向内核注册所述ARM二进制文件的打开方式；

启动Android应用时识别所述ARM二进制文件；

通过所述已注册打开方式加载ARM二进制文件；

所述加载过程在Android系统中创建虚拟执行空间；

所述虚拟执行空间中构建虚拟ARM架构CPU；

所述ARM二进制文件运行在所述虚拟ARM架构CPU上；

所述虚拟ARM架构CPU遵循预设转换规则执行转换得到本地代码；

将所述本地代码推送到本地CPU上执行；

本地CPU上执行完回传数据结果给Android应用。

优选地，所述虚拟执行空间构建虚拟ARM架构CPU包括步骤：

收集ARM和x86指令集，并解析其功能；

在所述Android系统中虚拟出运行空间；

对所有ARM指令集进行逐条解析翻译并得到若干x86指令；

将翻译后的指令进行推送，并到本地CPU上执行。

优选地，所述加载所述ARM二进制文件到所述虚拟ARM架构CPU包括步骤：

安装满足解析和注册不同二进制文件的内核模块；

动态注册ARM二进制文件为当前平台可执行文件；

设置不同ARM二进制文件的默认打开方式，且加载至ARM虚拟CPU的运行空间中，进行转换执行。

优选地，所述遵循预设转换规则执行转换得到本地代码包括步骤：

将目标代码翻译成等价的微操作指令；

对所述微操作指令进行拷贝、修改和链接；

产生所述本地代码。

本发明的有益效果是：扩展Linux系统x86架构上的应用生态，给用户带来丰富的内容体验和更加智能的人机交互体验的同时，还能保证最低程度的减少对CPU的性能损耗，避免大型应用运行时出现卡顿。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本发明提供的一种应用于Android系统x86架构上的ARM指令集转换方法的流程示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明了，下面结合具体实施方式并参照附图，对本发明进一步详细说明。应该理解，这些描述只是示例性的，而并非要限制本发明的范围。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本发明的概念。

如图1，在本申请实施例中，本发明提供了一种应用于Android系统x86架构上的ARM指令集转换方法，所述方法包括步骤：

S1：Android系统开机通过binfmt_misc向内核注册所述ARM二进制文件的打开方式；

S2：启动Android应用时识别所述ARM二进制文件；

S3：通过所述已注册打开方式加载ARM二进制文件；

S4：所述加载过程在Android系统中创建虚拟执行空间；

S5：所述虚拟执行空间中构建虚拟ARM架构CPU；

S6：所述ARM二进制文件运行在所述虚拟ARM架构CPU上；

S7：所述虚拟ARM架构CPU遵循预设转换规则执行转换得到本地代码；

S8：将所述本地代码推送到本地CPU上执行；

S9：本地CPU上执行完回传数据结果给Android应用。

在本申请实施例中，所述虚拟执行空间构建虚拟ARM架构CPU包括步骤：

收集ARM和x86指令集，并解析其功能；

在所述Android系统中虚拟出运行空间；

对所有ARM指令集进行逐条解析翻译并得到若干x86指令；

将翻译后的指令进行推送，并到本地CPU上执行。

在本申请实施例中，所述加载所述ARM二进制文件到所述虚拟ARM架构CPU包括步骤：

安装满足解析和注册不同二进制文件的内核模块；

动态注册ARM二进制文件为当前平台可执行文件；

设置不同ARM二进制文件的默认打开方式，且加载至ARM虚拟CPU的运行空间中，进行转换执行。

在本申请实施例中，所述遵循预设转换规则执行转换得到本地代码包括步骤：

将目标代码翻译成等价的微操作指令；

对所述微操作指令进行拷贝、修改和链接；

产生所述本地代码。

从现阶段的主流体系结构来看，指令集可分为复杂指令集(CISC)和精简指令集(RISC)两部分，相应的，微处理随着微指令的复杂度也可分为CISC及RISC这两类。CISC(复杂指令集计算集)全称为Complex Instruction Set Computers，RISC(精简指令集计算集)全称为Reduced Instruction Set Computers，其中CISC以Intel、AMD的x86 CPU为代表，而RISC以ARM、IBM Power为代表。

CISC指令集可以直接在微代码记忆体(比主记忆体的速度快很多)里执行，新设计的处理器只需增加较少的电晶体就可以执行同样的指令集，也可以很快地编写新的指令集程式，用来减少编程所需要的代码行数，减轻程序员的负担。高阶语言对应的指令集包括双运算元格式、寄存器到寄存器、寄存器到记忆体以及记忆体到寄存器的指令。

RISC指令集包含了简单、基本的指令，透过这些简单、基本的指令，就可以组合成复杂指令，每条指令的长度都是相同的，可以在一个单独操作里完成，大多数的指令都可以在一个机器周期里完成，并且允许处理器在同一时间内执行一系列的指令。

RISC的设计初衷是针对CISC CPU复杂的弊端，选择一些可以在单个CPU周期完成的指令，以降低CPU的复杂度，将复杂性交给编译器。举一个例子，CISC提供的乘法指令，调用时可完成内存a和内存b中的两个数相乘，结果存入内存a，需要多个CPU周期才可以完成；而RISC不提供“一站式”的乘法指令，需调用四条单CPU周期指令完成两数相乘：内存a加载到寄存器，内存b加载到寄存器，两个寄存器中数相乘，寄存器结果存入内存a。按照此思路，早期的设计出的RISC指令集，指令数是比CISC少些，但后来，很多RISC的指令集中指令数反超了CISC，因此，引用指令的复杂度而非数量来区分两种指令集。

CISC实现时，是将复杂指令转换成了一个微程序，微程序在制造CPU时就已存储于微服务存储器。一个微程序包含若干条微指令(也称微码)，执行复杂指令时，实际上是在执行一个微程序。这也带来两种指令集的一个差别，微程序的执行是不可被打断的，而RISC指令之间可以被打断，所以理论上RISC可更快响应中断。

在此，可以看出CISC和RISC的主要区别：

CISC的指令能力强，单多数指令使用率低却增加了CPU的复杂度，指令是可变长格式；RISC的指令大部分为单周期指令，指令长度固定，操作寄存器，只有Load/Store操作内存；

CISC支持多种寻址方式；RISC支持方式少；

CISC通过微程序控制技术实现；RISC增加了通用寄存器，硬布线逻辑控制为主，适合采用流水线；

CISC的研制周期长；

RISC优化编译，有效支持高级语言。

本发明提供了一种应用于x86平台的ARM指令集转换技术，即从指令集分类来看，提供了一种把RISC指令转换成CISC指令的执行技术，该技术采用动态翻译的技术，先将目标代码翻译成一系列等价的被称为“微操作”(micro-operations)的指令，然后再对这些指令进行拷贝、修改、链接，最后产生一块本地代码，这些微操作排列复杂，从简单的寄存器转换模拟到整数/浮点数学函数模拟，再到load/store操作模拟，其中load/store操作的模拟需要目标操作系统分页机制的支持。

该技术对代码的翻译是按块进行的，并且翻译后的代码被缓存起来以便将来重用，在没有中断的情况下，翻译后的代码仅仅是被链接到一个全局的链表上，目的是保证整个控制流保持在目标代码中，当异步的中断产生时，中断处理函数就会遍历串连翻译后代码的全局链表来在主机上执行翻译后的代码，这就保证了控制流从目标代码跳转到转换程序代码。简单概括如下：指定某个中断来控制翻译代码的执行，即每当产生这个中断时才会去执行翻译后的代码，没有中断时仅仅只是个翻译过程。

该技术二进制翻译大致过程如下：目标代码中的一条指令--转换成微操作--转换成主机代码，二进制翻译将target_arm_instruction翻译成host_x86_instruction，完成这个工作的是ky_tcg模块，为了移植性和通用性方面的考虑，定义了ky_mirco_op，首先该技术会将target_arm_instruction翻译成ky_mirco_op，然后ky_tcg将ky_mirco_op翻译成host_x86_instruction。

执行代码翻译流程如下：target_arm_instruction->ky_mirco_op->ky_tcg->host_x86_instruction，将目标代码的指令一条条地解释为微操作，通常来说，一条目标指令，可能被解释成一条或者几条微操作，因此这个过程是会让目标代码的执行过程比原来慢的，微操作是精挑细选的，它们的组合基本上可以完整地表示不同体系下的所有指令，从目标代码中的指令，到微操作的转换过程是由核心转换代码完成的。

从微操作到主机系统的转换过程，实际上是复用了GNU C编译器的既有功能，因为微操作是用C语言编码的，所以直接将这些微操作通过GNU C编译器编译成主机系统的代码，这是一个很取巧的做法。事实上，当该技术在运行阶段，这个编译过程已经完成了，即每个微操作的主机代码已经生成了，就像是已经在手头上有了一大把的零件，只需要将这些零件按照目标文件的图纸组装在一起，就生成了一个可以在主机系统上运行的程序。

总结起来就是，该技术加入了很多精妙的设计，每个微操作都被编写成一个C函数，一般都是很简短的C函数；微操作中如果有常数参数，常数参数是动态生成的，如何让它能够作为“常数”形式写到主机代码中呢？答案是用到了GNU C编译器的relocate功能，C程序如果引用到了内存地址的话，因为编译时无法预计运行时的某个变量或者函数的地址，因此编译时并不能准确地解释这个地址具体是多少，编译时都会将这个对内存地址的引用位置用0x00000000(32位系统)代替，再通过维护一张重定位表(relocation table)，来指定代码中哪些位置应该到用哪些运行时的地址填充。该技术就是利用了这个机制，用对内存地址的引用给常数先占个位置，然后自己用常数的具体值再覆盖掉这个位置，反正这些代码在内部马上就要组装执行了，也不需要GNU C的链接器真正去做链接操作了。在组装过程中，转换技术使用C函数memcpy将微操作的C函数生成的目标代码，去掉GNU C编译器生成的prologue/epilogue，直接拷贝到主机代码缓存ky_gen_code_ptr中。

微操作的主机代码位于ky_opc_ptr处，参数位于ky_opparam_ptr位置，这部分主要是创建了一个为执行ky_tcg翻译和执行的线程，它的函数是_ky_tcg_cpu_thread_fn，这个函数会调用ky_tcg_exec_all，最后执行主函数(ky_cpu_exec)，主要是处理中断异常，找到代码翻译块，然后执行，将翻译好到代码块暂存起来，因此首先会去查看该pc对应的代码是否已经翻译，如果已经存在直接返回，否则就进入ky_tb_find_slow，进行翻译，进入ky_tb_find_slow后会调用ky_tb_gen_code，首先分配TranslationBlock描述符，将要翻译的pc等信息记录下来，然后调用ky_cpu_gen_code，这个函数完成代码翻译工作。这个工作会将翻译好的代码存在一个缓冲区里面，在ky_cpu_gen_code里面首先是将target_arm_instruction翻译成ky_mirco_op，然后将ky_mirco_op翻译成host机器码，将target翻译成中间码时，将操作码和操作数分开存储，分别存在ky_gen_opc_buf和ky_gen_opparam_buf中。翻译的过程就是不断向ky_gen_opc_buf和ky_gen_opparam_buf中填充操作码和操作数。接下来就是ky_tcg_gen_code，ky_code_gen_prologue是ky_tcg的入口函数，在ky_tcg初始化的时候会生成相应的代码，翻译代码块的执行入口函数主要是保存寄存器的状态，然后将ky_tcg_tb_exec传进来的第一的参数(env)给KY_TCG_AREG0，然后跳转至ky_tb_ptr，开始执行代码。同时代码执行的返回地址也确定了，返回后恢复之前保存的状态。

本发明的有益效果是：扩展Linux系统x86架构上的应用生态，给用户带来丰富的内容体验和更加智能的人机交互体验的同时，还能保证最低程度的减少对CPU的性能损耗，避免大型应用运行时出现卡顿。

应当理解的是，本发明的上述具体实施方式仅仅用于示例性说明或解释本发明的原理，而不构成对本发明的限制。因此，在不偏离本发明的精神和范围的情况下所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。此外，本发明所附权利要求旨在涵盖落入所附权利要求范围和边界、或者这种范围和边界的等同形式内的全部变化和修改例。