本文内容源视频地址：
https://huaweicloud.bugu.mudu.tv/watch/ym1bzp7p
大家好，今天要讲的主题是关于软件迁移，这是一个久远的话题，因为但凡牵扯到切换平台、CPU架构的变化，甚至一些语言版本的升级，都可能会面临到软件迁移的问题。今天我们就探讨一下软件移植过程的原理，以及如何进行软件迁移。
在软件移植的过程当中，如何帮助开发者提升效率，如何把华为沉淀下来的软件开发以及移植的经验反馈给开发者，帮助开发者加速软件开发的进度，降低成本，这是我们一直关注的问题，为此，我们还推出了鲲鹏的开发套件，帮助用户做软件的移植，以及做基于鲲鹏平台的性能加速。
其实一提到软件移植，如果是做了比较底层软件的话，大家可能会用到一些汇编这样的底层语言。它和机器的硬件架构强相关，当你在从一个平台切换到另外一个平台的时候，这些强相关的语言势必要进行一次代码移植，跟我们所采用的编程语言以及移植的平台环境强相关。当我们用汇编代码或者是用这种编译型语言的时候，就会面临着一些移植的问题和挑战，有些问题通过编译器能解决，有些问题特别是一些低阶的代码或者比较底层的代码，就要手工去查手册，然后去把它相应的转换成新平台所使用的机器码。
上图列出了鲲鹏处理器和x86处理器的指令差异，列了一个简单的两个数相加，两个int型相加的这样一个简单程序。通过GCC编译完之后，通过OMGD，就能看到指令的具体的格式形式以及相应的对应的汇编代码。可以看出，对应x86平台而言， X86是复杂指令集，鲲鹏是完全兼容Arm64架构的，指令集也是和Arm64精简指令集是完全兼容的。
这里讲一下背景，其实所谓的精简指令集和复杂指令集的区分是从上个世纪70年代开始的，IBM曾经做过一个研究，关于CPU如何去高效的运行，他们发现有些常用的指令或者是程序代码，常用的和不常用的有很大的差异，又因为集成电路的制程、工艺或器件的设计水平没有现在这么突飞猛进，就会想如何把CPU从硬件上设计简单一点，从软件上高效一点，所以就提出了精简指令集这个概念，其最大的特点就是它的指令宽度是相等的，每个指令执行的周期几乎也相同，它把很繁杂的事情做的尽可能的简单，然后用很多简单的操作去完成一件复杂的任务。
从相反的复杂指令集的，我们看一下x86下面的复杂指令集，它每一个指令的长度是不同的，像这里列举的mov和add这两个指令，它的机器码、指令码是不同的，长度是不同的，势必会造成IC器件的解码器，到软件流水操作上处理的步骤是不一样的，也必然会导致每条指令的执行周期不同，但是这样也有一个好处，就是一个指令就能完成一个比较复杂的事情，尽管说指令可能会变得很长，但是一条指令能完成一比较复杂的事情，对上层的程序员来讲，会容易理解一些。
这就是精简指令集和复杂指令集的一个简单背景，我们能看到，在反汇编下来的x86指令集和鲲鹏指令集的汇编代码上，操作指令是完全不同的，寄存器的命名也是完全不同的，在x86的平台上，有16个通用寄存器， x86 64模式下，有16个通用寄存器，浮点寄存器，根据支持的MMX技术或者SSE技术。
反观鲲鹏平台，因为是和Arm64指令兼容的，所以指令集要完全对照，从这个角度来讲，鲲鹏平台有31个通用寄存器，除了这31个通用寄存器以外，还有一些状态寄存器或者是一个栈寄存器，对应到浮点寄存器，就有32个叫做单指令多数据这样一个寄存器，32个寄存器位，位宽是128，这一点是和x86 64平台是有差异的，比如说x86 64如果支持AVX512的话，那么它的位宽是512比特，从这个角度上，硬件器件差异是非常明显的。
从反汇编的角度来讲，不知道大家有没有注意到x86平台上有一个mov指令。从第一行我们能看到从寄存器rbpmov一个存储数据，到EDX这样一个寄存器，把变量从内存里拷贝进来。同样的一件事情，在鲲鹏处理器上加载数据到寄存器的指令就变成了LDR，加法指令仍然是add，存储时对于x86来讲，是从寄存器mov到了内存里，但是对于鲲鹏平台它是用str指令，这也反映出精简指令的特点，它是用load stall模式，也就是说在鲲鹏处理器平台上不支持内存到内存的直接访问，必须要经过寄存器作为桥接来中转。
这是和x86指令复杂指令集不同的另外一个地方，还有就是在x86平台上，它的内存访问的模式非常多，对于公共平台上就没有那么丰富了。以一个程序为例，我们简单列举一下，从CPU的角度来看，同样是一段C代码，CPU做了不同的事情，执行了不同的指令，那么经过不同的周期不同的运算以后，它会输出最终计算的一个结果。当然从这个角度来讲，从这段程序两个平台是没有任何差异的，除了指令上以外，执行结果不会有任何变化。
跨平台移植软件要面临的不少问题，因为软件移植本身就是一个工程性问题。这里通常第1步来讲，如果说我们决定从x86平台迁移到鲲鹏平台，就要去判断一下这个软件迁移值不值得，困难有多大？目前常用的做法就是把x86平台，相应的软件包拿下来，然后去看它的依赖性关系。看看这个软件，如果跑在x86平台上，他依赖哪些第三方组件？这些第三方组件在目标平台上存不存在要做一些判断，这种判断通常都是这个平台之间的反反复复的安装，去运行，然后根据系统报出来的错误去一个个来排除，这都是通过人工来完成的，如果有移植经验的同学就会觉得比较费劲，很繁琐琐碎，不小心就错，可能还找不出来。
当解决完第1步编译过程的问题之后，可能会还碰到跑过之后，结果新平台上出现了function fault，功能性错误原因比较多，有的是软件逻辑有问题，第2个可能是第三方组件的跨平台兼容性有问题，第3个可能是系统本身支持度也有问题，影响因素比较多，这就需要移植之后，技术人员去定位，定位对工程人员来讲，专业技术要求会比较高，也存在着一个反复编译、反复调整、反复验证，这个过程成本会很高。
当完成了功能验证，跑过一些基本测试以后，可能又会面临的一个性能问题，当用在工作环境、生产环境的情况下，因为生产环境的软件都希望用最小的硬件跑出最大的性能，跑出最高的性价比，这时候都会对软件性能有要求。就不得不采取一些方法，例如用一些商业软件，或者一些开源的软件命令，去分析软件的瓶颈到底是哪里有问题？是系统有配置的参数有问题，还是软件本身逻辑有问题？
这三步是我在软件开发过程当中积累下来觉得比较重要的三步，对软件的质量、移植的质量有决定性影响。这三步对于任何人来讲，可能都不是一个能轻松逾越的障碍。
再稍微解释一下，对于软件移植这件事情，通常我们讲的是编译型软件会面临的困难，对于解释性反而比较轻松，为什么？比如像现在常用的Java或者Python，甚至Go，我们的依赖是什么？依赖的是语言所提供的虚拟运行环境，甚至是像Java提供的Java虚拟机JVM，只需要选相应平台的JVM安装，就能把底层的所有差异性都屏蔽掉。
软件根据运行环境去跑，通常是没有问题的。对于像C,C++这种，作为编译，甚至可能会调用C,C++这种组件的软件，就需要对C,C++进行移植，分这几种情况：
第1种是开源软件，通常是和社区进行合作，让社区去支持空洞平台，或者是支持ARM64的平台，这样就能一劳永逸的解决问题。对于自研软件，不能开放代码，就需要进行商业合作，引导客户移植到鲲鹏平台上。
对于商业软件，最典型的，比如说像微软的一系列软件，或者是Oracle的软件数据库，不可能去获得源码，去推动他们和中国的软件界合作，可能也非易事，那么这个时候只能找到要么是合作，要么就是找一个替代方案，如果实在是不能替换用户的业务，又不能去修改，就不得已采取一个鲲鹏平台和x86进行混合部署，这是一个软件部署方面的策略。
还有一种就是对于常用的windows平台的系列开发，windows虽然一年多前说要支持Arm64这个架构，但实际上到现在为止他也没有宣布，商业上的考虑或者是其他的因素可能都考虑的比较多，对这样大体量的公司，windows平台就是进行有限度的在开源生态里面进行有限度的支持，比如说像微软的C#，.net core3.0已经开源了，已经在Arm平台上能够用起来了。换句话来讲，我们也可以在鲲鹏平台上基于.net core3.0支持C#。对于鲲鹏软件移植的过程，我们把它分解为这样几个步骤流程，其中最重要的就是所列到的第2步第3步以及性能达标分析这一步，我们现在提供了相应的每一步提供一些辅助工具，去帮助客户进行用户开发者进行分析进行移植。
二进制文件依赖扫描，我们提供了一个工序软件进行软件安装、依赖库的扫描和软件运行依赖库的扫描。根据长期积累的有一个兼容性清单，这个兼容性清单覆盖了市面上大多数流行的或者常用的OS以及相应的版本，还有相应的GCC的版本，对于移植的第二阶段，像移植修改C，C++源码，我们也同样提供了一款工具去做C，C++源码的分析，这个分析主要是集中在几个方面，汇编代码、边选项，宏定义， builtin函数和编辑提供的builtin函数和attribute，去重点检查用户的Makefile和CMakeList。如果用户软件是用make构建的或者CMake构建的，那么我们能帮助去发现，识别一些移植中需要修改的地方，同时我们会给出移植修改的建议。
当移植完成之后，我们会提供一个性能分析的工具，帮助用户去check这个软件是不是能够达到工作标准，也就是check它的性能指标，我们会进行系统性的性能分析，也会去做软件级的热点定位分析。然后在此基础上会给用户提供华为积累下来的比较有效的一些软件优化的方法，这个就是我们今天要介绍的三款软件，通过这三款软件我们就能比较方便的或者比较高效率的完成C，C++代码，从X86平台向鲲鹏平台迁移。
在C，C++软件移植的过程当中，要着重考虑三个方面的问题，第1是软件构建文件的差异。这里面举两个例子，一种是方案里面，可能在x86平台上常看到一个叫-M64的这样一个知道编译选项的option，这个含义，实际上是要这个软件生成为64位模式的，我们编译目标代码的ABI。实际上在鲲鹏平台上，可以用类似的，用-mabi=lp64去来替换，当然如果安全的情况下，加上-FPIC就生成一个flowting的address，来屏蔽底层的相关依赖性，这样就能达到一个编译选项M64的替换。
还有一个就是对应Arm指令集替换，常用的可能会见到一些-march参数，在x86的平台上提供了多达二三十种架构平台，从Intel到AMD的各种各样的，Arm平台来说，就相对简单一点，只需要去选用鲲鹏平台，CPU所支持的兼容Arm的架构。如果版本比较新，比如说9.1以上的，可以选用-mtune=tsv110。这实际上是泰山微内核110这个型号在GCC内部进行了一些措施，针对架构做的一些的public的tune优化，能够提供一个相对较好的性能，性能增加，有5%~10%的性能提升。
接下来第二部分就是C，C++源码的移植，这里也举两个例子，第1个例子是基本数据类型，尽管说鲲鹏平台支持的是LP64，x86平台也支持LP64，但是实际上大家在某些细节定义上还是有区别的，虽然字符宽度，比如说对char来讲都是8字节，但是x86 char是有符号类型的，对于鲲鹏平台，是无符号类型的，这块的改动就可以通过修改makefile，加一个参数，把默认的无符号的char定义成有符号的char，这样就能保证C代码逻辑，关于char操作上不会引入歧义。
第2类问题就是编译器当中提供了多达数百个的宏定义，比如用GCC的话，可以在C，C++的软件里面，源文件里面直接使用相应的宏定义，那么这个宏定义在编译的时候，编译器直接做环境变量的check，然后直接设置了相应的正确的值，跟host环境相关。这里指编译和运行在同一款机器上，我们不讲host和target相异的情况。这个时候对于相应的软件，可能需要区分一下宏定义，比如说像x86 64，显然一看就知道是支持x86的，不可能在鲲鹏平台上运行，这时候就会建议用户去修改用户代码，用预编译的方式做软件范围的定义隔离，对于鲲鹏平台，常用的关键字就是aarch64或者是Arm64，去做软件逻辑的定义。
第3类问题就是汇编代码的移植，这也是最头疼的一块，因为x86平台有大概2100个汇编指令，鲲鹏平台因为兼容Arm64，有1000~1100个汇编指令，加起来有3000多条，如果想把它分清楚，是非常痛苦的。Intel的相应指令集的手册有4000多页，Arm相关指令集的手册有7000多页，纯英文的文档大家读起来肯定会崩溃的，所以汇编代码的移植，是一个难点。
汇编代码在软件过程中表现有若干种形式，第1种是纯粹的就用Asm关键字写汇编代码，第2种是用builtin函数做替换，举个例子，GCC里提供了builtin的CRC的32计算的一些加速指令，我们可以去寻找鲲鹏平台上的相应的指令进行替换，比如说像x86平台上用到的预取的指令，我们也可以找到鲲鹏平台上的builtin函数做替换。接下来还有第3种，就是可能会用到的Intrisic。Intrisic实际上是在GCC里提供的像C语言一样去使用的汇编函数，那么引出Intrisic在x86平台上和Arm64平台，相差非常的大。
在x86的平台上Intrisic总数将近7000个，在鲲鹏上就差的比较多，远远少于这个数，为什么？这是因为在x86平台上它支持的指令集比较多，经过二三十年的演进，有MMX的指令集，有SSE的指令集，还有AVX，AVX也分了128比特、256、512比特的三种。每一种它对应的Intrisic非常的多，所以移植的数量非常大。在这个里面可以找到一些，比如说对于128比特的操作进行一些对应，可以做一些替换。
针对上面提出的这些问题，我们提供了几个工具：分析扫描工具，代码迁移工具、性能分析工具。
比如说这里优化了glibc基础运行环境，优化的压缩、加密、加解密，包括数学计算这样一些开源的或者是三方的组件，优化了IPP信号处理的一些程序功能提升，就是用软硬结合的方式极大提升了性能。这里面大致分析的一个流程，在分析扫描里面，把用户的软件上传到工具环境下，工具环境就会分析用户X86平台上软件的安装包，比如说RPM包还有一些JAR、Java类的程序，包括压缩包，会去扫描识别里面软件包内部以及软件安装路径内，包括压缩包内部集成的，比如说SO文件、二进制文件，去检验是否在鲲鹏平台上不同的操作系统上是否支持，反馈用户一致性的分析报告，逐个告诉用户SO是否兼容，不兼容的话怎么去处理？我们会提供链接，是源码级的链接，或者是提供移植文档方式书的这种链接，都会在报告里提供出来。
这个工具提供了两种工作方式，一种是通过命令行的方式，这种形式通过参数输入，一种是通过外部方式，在做了安装包的依赖性分析以及源码的扫描之后，会给用户产生一个移植分析指导的报告，这个报告提供CSV的格式或者是HTML的格式，用户可以去下载，里面会详细罗列出哪些依赖库，哪些二级制文件需要移植，然后哪些C，C++以及汇编代码，需要移植规模有多大？会给用户呈现一个移植的工作量，比如以每月为单位提供一个工作量。
计算标准，用户是可以自己输入的，如果说你的编码能力强，那么你一个月C,C++代码，可以完成800行，汇编代码你可以完成600行，对吧？如果你的移植能力有限，有的编码能力有限，技术成本有限，那么你可以设置成比如C,C++代码一个月300行，汇编代码100行，它会根据不同的标准，计算出移植工作量，做工程技术上的第1步，第1步信息掌握。
这里就列出了我们主要的功能，前面我已经基本讲述过，SO文件的检查，构建工程的检查、源文件的检查，评估一致性，然后进行工作量评估，两种方式：外部方式和命令行方式。
通过这个工具，就可以拿到软件移植工程量的第1手资料，然后决定是否移植。当决定移植之后，就可以用代码迁移工具去做进一步的分析，代码移植工具主要是分析用户的源代码，它着重分析的是makefile，C，C++的源码，就包括我们这里的编译器提供的宏定义，然后用户自定义宏，还有builtin函数、Intrisic、汇编代码，我们分析完这些内容后会提供一个详尽的移植指导，这里面就包含makefile怎么修改？C，C++代码怎么修改？汇编代码怎么修改？
这一页就列出了代码移植工具的大致工作流程，同样我们也是外部方式和命令行方式两种方式，方便用户做选择。我们分析用户的源码构建工程，还有构建工程配置文件、C，CC+的源码和汇编源码，然后给出移植指导，对于源码的变化，我们会提供对比的方式显示，像这里举的例子就是左边第1点是我们要改哪些文件，修改文件列表，第2类就是我们源文件是什么样子，第3类就是建议修改成什么样子？
这是软件移植工具所能提供的能力，这里还是针对C，C++，目前为止C，C++的这样编译型语言,去做了建议值，然后要有源码，没有源码，也就谈不上移植了。
前面已经讲了如何去做软件依赖性的分析，通过华为开发套件去做软件依赖性的分析，以及做C,C++的移植，在完成移植之后，会在生产环境上去跑这个软件，这个时候会去做性能分析，我们提供了性能分析工具，这个工具主要是帮助用户去做软件性能定位，比如说有性能瓶颈或者想继续优化，我们提供了一些手段，这里对于这个工具我们可以帮助用户去分析处理器相关指标，以及看到调度的一些信息，包括外设的信息、CPU、磁盘，甚至网卡、短期性的数据，去帮助用户分析C，C++或者是Java程序这样一个性能指标。
Java类不是说把JVM当成一个进程，我们是看到JVM内部的，还是有一定作用的。把这些数据统统的分析起来，然后通过自己定义的数学模型进行分析，去看到用户的软件性能瓶颈，比如说是资源竞争的问题或者是调度的问题，甚至比如说有一些bug导致了一些次循环等，我们提供了多种的方式来呈现这样一个结果。比如常用的火焰图的方式，能够比较直观帮助用户去看自己的软件里有没有性质上的问题。
这个是罗列的目前性能分析工具能够提供的性能指标，比如说硬件器件相关的，CPU、内存、磁盘、网卡、系统级的，我们也能看线系统调度比如说进程、线程，还有彼此之间的切换，或者是资源的争抢，锁一些关键变量的性能分析先行指标，我们也提供了一个基于火焰图、基于代码逻辑的深层次检查，能够提出用户代码的真正的开销，大的地方在哪里，对应的代码对应到源码。
通过这样的手段，就能帮助开发者比较快的定位自己的软件，编译型软件的瓶颈。当定位到软件瓶颈的时候，我们会提供一些附加的能力，比如说这里就提供加一个叫加速库，软硬结合的加速库帮助用户去优化代码。
除了泰山内核，可以多达48甚至64的内核以外，我们还提供了一些额外的能力，额外的一些引擎，这些加速引擎就可以支持，比如说压缩LZ的这种算法，还有加解密的，比如说非对称的，还有对称加密的，包括一些常用的变加解密的这样算法，比如说DH编码等等。
我们还支持了比如说存储用到一些常用的软件算法，把它运化成加速器，这种压缩用起来非常简单，就跟用一个外设一样，只需要从华为的网站上去获取相应的硬件驱动代码，把它安装上之后，就可以像一个正常的外设去使用它。
当然了，你要使用我们提供的一些API的话，要遵循我们提供的用户手册，修改源码，比如说可能原来掉的一些是软件的这样一些函数，或者是三方组建的API，要用加速器的话，就需要根据API修改相应的代码逻辑，但这个代码逻辑只是存在于API层面。
这里举个例子，比如说集成了一个叫RSA的加速的引擎，是用来计算加密的，我们支持1024~4096，4种：1024 2048 3072 4096，4种密钥长度。在加速器引擎里面，是通过一个用户态的来lib去做隔离，对上去隔离用户的，比如说开源的第三方软件，比如说OpenSSL的的API，去对接OpenSSL API也可以把API暴露出来，直接给用户的APP去使用，在lib下层的就是IC引擎的相应的驱动，用户可以完全不用知道下面细节是如何实现的，只要正确调用鲲鹏RSA的提供的用户lib，就可以去使用加速器的硬件计算能力，极大的加快了RSA的计算。
RSA计算如果用CPU算的话，是相当费时费力的。比如像x86的一个中高端的CPU，它每秒钟只能执行720次左右RSA2048的计算。但是你要用到了鲲鹏920提供的RSA计算引擎的话，计算量将是大幅度的提升，也就是说，可以把原本用来计算RSA的这些CPU完全释放出来，跑其他的业务！在一个芯片内完成这项业务，对用户来讲就会提供另外一个选择，不需要去买某些PCIE的插卡，直接去用软件的方式来提升软件性能，达到一个比较简单的提升性能的方式。这是我们举的一个例子，在移植工具里面，都会去通过软件移植的这些能力去提供给开发者直接使用。
这是几个工具组件的发布策略，我们目前停留在中间这一列，我们完成了多OS的适配，比如说支持CentOS7.4、7.5、7.6、7.7，支持中标麒麟等，支持了像SuSE这样的操作系统，尽可能的去覆盖常用的操作系统的类型，我们也支持了GCC的多个版本，从4.8.5一直支持到目前为止至少8.3，后续会支持到9点几的版本，一直往上支持上去，帮助客户尽可能的简化重复劳动，我们还支持make构建工具，支持CMake构建工具
支持C，C++的代码移植，也支持汇编代码的识别，前面说了，从汇编指令的角度来讲，从Intrisic的数量来讲，这个量非常的大，而且也很有技术挑战的，就是汇编语言的替换，所以这块我们会逐步完善。对于加速这一块，我们提供一些Intrisic的替换，比如说AVX或者SSE。
我们也优化了一些常用的加速的三方的组件，像z-lib的加速或者stapi的加速，还有scan这种字符扫描的加速，用鲲鹏的指令去进行优化，进行性能提升，取得了比较可观的一个性能改变都是50%，一倍，甚至更多的3，4倍的性能提升，加速的效果还是挺明显的。这样也能让用户的软件应用跑的又快又好。
如何去获取这几个工具，可以去鲲鹏社区去下载相应的软件，
对于加速库软件，这里的策略是主要采取开源的策略，比如说像一些压缩算法，压缩引擎的，包括这些软件组件，都是把相应的patch推动到社区。对于硬件加速引擎，是直接可以从华为的鲲鹏社区上去下载，然后去安装使用，取用起来很方便。
鲲鹏社区是华为重点建设的和开发者沟通互动的桥梁。在社区里，可以下载到数百份的软件移植指导以及相应的软件调优的经验，可以在这里面和其他的开发者做互动，做技术上进一步的探讨。很多新的技术资料、技术文档，包括一些白皮书，一些产品设计方案都会在社区里陆续发布，不同的开发者都能得到一些不同的信息。
随着鲲鹏计算平台的壮大，应用越来越多，需要大量的开发者去投入到平台的生态建设里面来。所以华为在这里推出了这种线上认证培训一系列的技能提升的活动，包括在线课程，云端的实验室，线上认证和线下培训，希望大家能够积极参与，来共同构建华为鲲鹏的生态软件生态。
好，这就到最后一个提问互动环节了。线上的开发者有什么问题吗？我们可以交流一下。
第1个问题是王涵，他这个问题是软件移植是基于同样的操作系统移植吗？
我们的移植分析工具不是依赖于操作系统的，也就是说我们软件可以跑在不同的操作系统上，例如，最终的软件移植可能是移植在一个Ubuntu上，甚至说一个中标麒麟上。其实对于软件移植人员来讲，重点要关注的就是软件运行依赖库或者是安装依赖库的一个兼容性问题，就是积累一个兼容性清单。
第2个问题，从x86移植到鲲鹏，会不会导致性能急剧下降？
要看应用的类型。如果你是一个纯粹的C,C++做一些通用计算的话，那么我能说是不会，但是如果说你C,C++里面非常高级的，你用了一些底层的汇编，如果用到了一些x86所独有的，比如说AVX做一些向量化计算，或者是做一些这种高并发的计算，我不得不坦率的告诉你，性能软件，因为AVX指令或者是不管无论是256比特大概是512比特，那么在鲲鹏920平台上现在是没有对应，但是以后会有对应。这是一个长期的演进的计划和过程，如果你要用到这些AVX指令，那么我们是有性能差异的。
第3个问题，鲲鹏与手机处理器都是基于精简指令集，能否认为可将手机一起底层的功能移植到鲲鹏平台上？
这个是我们现在常说的所谓的端边云融合，实际上做手机端开发，我们可能更多的是基于安卓的系统，然后做一些用一些Java类的语言，然后我们的应用可能是编译成字节码跑的JVM上。
从这个角度来讲，如果说你单纯从语言，我可能说差异并不大，在鲲鹏平台上你可以方便装一个安卓模拟器，通过这种方式，我们也提供这样一个解决方案，让你可以跑一个云手机，在官方平台上看云手机，跑得非常的高效，所以从这个角度来讲，我们提供了一套解决方案，没有任何问题。
第4个问题，Java代码如何移植？
这个问题在前面的胶片上我们已经看了，因为Java属于这种字节码运行的，那么于强依赖于他的runtime环境，那么在我们华为鲲鹏平台上，我们是完美支持OpenJDK的，所以你用Java，代码语言是没有问题的。但是如果说Java里面非常高级的，你又嵌套了一些C的一些API，那么请把C单独的源码拿出来做一些一致性的检查。
第5个问题，目前提供什么移植工具？
Java刚才说的，我们在这个工具里面不去做涵盖检查，除非你Java，或者是像类似于这种Python，你用到了一些C编译成的SO文件用到一些C提供的API，我们是要检查。
来源：鲲鹏头条