houdini 技术



houdini 是intel 研发的ARM binary translator。

它的原理在于把ARM的二进制代码转译为X86指令集，使得可以在X86的CPU上执行。

Intel是移动市场的新进者，最近出了几款面向移动市场的SOC，面对应用程序支持缺乏的问题，有两条路可以走：

1.逐家拜访应用开发商，要求他们重新为intel的cpu编译一份应用。

2.使用二进制转换，使得已有的应用可以运行在intel的cpu上。

该产品并不开源，可以在联想的K900 ROM里面可以找到二进制版本。一共有三个文件：libhoudini.so   libdvm_houdini.so  houdini_armlibs.tgz

原理是：当Dalvik VM加载lib失败时，程序流会再次尝试用libhoudini中的my_dlopen打开。该lib类似于QEMU的user mode emulator，通过虚拟一个ARM的CPU （包含指令集和寄存器，但是没有外设模拟），加载基于ARM指令集的lib。目前还不清楚是基于解析执行，还是JIT方式实现。

采用类似技术的产品有valgrind（模拟X86 CPU来检测程序内存泄露），qemu user mode（可以在X86 Linux下执行mips的elf文件）

类似概念的产品

• 为ARM服务器产品准备的二进制翻译软件  （X86转ARM指令集） http://server.chinabyte.com/345/12451845.shtml
• FX!32 (X86 windows程序运行在Alpha CPU的Windows NT上) http://en.wikipedia.org/wiki/FX!32

下一个有可能出现类似产品的领域：
binary translator for windows RT  （至于原因。你懂的：））

================================================

前几日拿到联想K900，这款机器无论是硬件还是软件都十分不错，工业设计也很强。但很多网友仍然关心一个问题，X86的应用兼容性怎么样？在他们看来，兼容性很大程度上影响他们是否购买这款机器。

经过测试，X86的应用兼容性已经做的十分完善，英特尔此前宣布可达95%的兼容性不假，大家大可放下心里包袱。不过英特尔是如何做到的，这背后的原因很多人并不知道。恰好在IDF上，笔者遇到了一位英特尔软件部门工程师，他通俗的讲述了其中的原因。

其实问题主要出在指令集上，X86使用的是SSE指令集，而ARM是用的NEON指令集，两者差异导致了应用不兼容。不过好在Android 的大部分应用运行在Dalvik虚拟机之上，并不依赖CPU架构，因此这些应用可以很好地跑在X86上。

支持Dalvik的程序占据大多数，但仍然会有一些应用绕过Dalvik。比如需要更高的性能或者需要硬件的支持的时候，前者通常是大型游戏，后者则是结合了感应器或者电源管理等硬件相关的应用。Angry Bird两者都不占，所以可以兼容，赛车游戏两者都需要，所以大多不兼容。

这些稍显复杂的应用数量并不低，且用户需求强烈。为了快速解决这些问题，英特尔试图通过技术去完善，开发了一种转换技术“Houdini”。“Houdini”相当于一个中间层，可以让原本不兼容的应用跑在X86上。但这种强行结合的技术运行起来往往效率不高，容易出问题，且会增加2%左右的耗电。

从源头解决问题显然是更好的办法，尽管速度会慢一下。自从英特尔和Android合作之后，英特尔就提供了X86的NDK。开发者只需在应用中支持这个NDK，应用在提交时会自动生成2 个App，设备在下载时会根据自己的架构下载合适的App。这种方法并不难，效果也最好，难的是如何让众多开发商甘愿合作。所以英特尔以及手机厂商会去和应用厂商挨个合作，督促其支持X86的NDK。

现在已经有很多大型游戏支持X86架构，包括极品飞车、Epic Citadel 等。用户大可不必担心，因兼容性引起的影响已经十分微小了。

况且用户日常使用最频繁的恰恰是那些十分简单、无需重新适配的应用。由于Android使用虚拟机，应用性能常遭人诟病，但是这样做的好处是，应用可以轻松跨平台运行。如果没有这个，那对英特尔来说将是灾难性的，从这点来看，英特尔还是十分幸运的。