关于操作系统跨平台cpu指令集移植的一些想法

实际上对于绝大多数普通的应用，只要操作系统本身跨CPU平台了，当然直接编译就可以切换到其他cpu处理器平台。

理论实践上只要接口不变，基本底层透明无感知。模块化。

以下部分为引用

不能直接重新编译使用的，要么是用了汇编代码，要么是用了CPU特有的功能，要么就是程序本身写得有问题。

补充：时国怀所说的，如果这样世界上只需要一个操作系统就够了。恰恰这句话是正确的，请大家有兴趣的去看 Debian 的网站，它就是致力于制作这样一个操作系统，目前它兼容数十种不同的CPU平台，而所有应用只需重新编译就可运行。

补充：实际上，题主的问题，我的理解是基于同款操作系统，同款硬件外设，不同款的CPU之间的移植。所以这里假设仅仅只有CPU不同。

有少数程序可以归纳到以上三类。
bsp代码，一般属于直接使用CPU特有功能的，不可移植。
硬件驱动，对同款硬件来说，一般是不涉及CPU功能只涉及特定硬件的，代码写得好就可移植，否则不可移植（用汇编代码的就要重写了）。
当然对硬件来说有个现实问题是不同款的CPU配合的外围硬件往往不同，这会需要不同的外围硬件驱动。
因滥用字节序造成的问题，可以通过宏定义解决，但如果只考虑x86跟arm，这两者的字节序是相同的。
不同之处在于arm对内存地址的边界对其要求很高。如果你的程序依赖不对齐的地址，也会造成问题，当然那通常根本就不是好的编程风格，所以归纳为程序没写好。

事实上，假定操作系统已经完整移植的情况下，就假定了操作系统的bsp已经完成了移植，主要的硬件驱动已经完成了移植。在此基础上，应用程序理论上可以直接重新编译实现移植。

不过现实要考虑的常常是另外一个问题：这些应用可能依赖某个过时的，已经淘汰的编译器才能正常编译，而那个编译器没有提供arm版本。为了移植，实际上是为了让老的代码能在新的编译器下编译，对Windows系统来说，这常常才是移植的困难。

而对Linux来说，gcc编译器数十年来一直都保持了不错的向下兼容性。这使得移植几乎无困难

Windows 8是怎么支持ARM的，是重新设计了BSP和硬件驱动以后才能在ARM平台上跑的，ARM平台上的硬件操作跟x86完全不一样，ARM汇编指令和x86的指令的差别就像一个是中文另一个是英文一样，甚至有些指令在这个平台上有，在另一个平台上就没有，比如x86里的IN/OUT指令。

软件是要通过操作系统支持才能运行，但也不是说操作系统支持了，软件就一定能运行，软件本身还是要有大量的汇编指令了，从x86到ARM转换，就意味着软件也要整个重新设计，不仅仅是有兼容的API就够用的。

在x86平台上，调用API都的用CALL指令，在ARM平台上，调用API用的是BL指令，这俩指令都不一样，怎么搞兼容性？

即使游戏厂商愿意在ARM平台上编译，那是不是代码一定就能运行了呢？肯定不是。要知道跨硬件平台做开发的成本是非常高的，正如我前面说的，不是拿源码直接编译一下就可以了。尤其是大型软件，涉及到各种硬件资源的操作（比如显卡，DirectX），不同平台上会很不一样。不同硬件平台上的系统时钟、调度策略、内存映射方式、DMA、PCI操作都有很大的不同，有些对于游戏开发来说，都是致命的限制，而且有些限制就是因为Windows没有提供接口，总不能让做游戏的厂商自己设计一套对应的硬件驱动吧？

为什么手机游戏可以跨平台，因为手机游戏是Java写的，Java的程序天生就不是硬件指令，所以跨平台没有问题，只要Java虚拟机支持就够了。但WAR3这些都不是Java写的，天生不具备跨平台属性。同样的道理，安卓的游戏你直接放到iOS系统里能运行不？肯定也不行。

世界上的硬件平台五花八门，除了ARM和x86，还有MIPS/PPC/SH/CF/SPARC....多数硬件平台都是不兼容的，甚至同一个架构的不同型号，也不是完全兼容甚至是完全不兼容的。不要被x86和Windows平台的兼容性影响而产生硬件都是兼容的错觉。不兼容才是常态。

我相信微软是想开放API的，但能不能开放，稳定性怎么样？是仅仅应用层支持还是包括内核和驱动？去看看WDK里看看微软给的文件系统驱动代码，连字节序都没考虑过，就这玩意直接移植？跨平台开发是个坑，因为历史问题估计微软自己已经掉到坑里了，什么时候爬出来不知道，但我估计微软想爬出来，而且不爬出来自己会死的很惨。

目前跨平台移植操作系统有几个问题：
1. 字节序问题，当然现在一般arm也是用和x86一样的字节序，但也有可能不一样
2. SIMD问题，x86下的SSE MMX指令在arm上没有，要用NEON重新实现这些算法
3. 性能问题，arm的计算能力不如x86，有些在x86上运行性能还可以的软件，到arm上要重新做优化
4. 个别bug，比如arm和x86调用函数的方式，参数传递入栈的方式不一样，有些小的栈溢出问题在x86上没事到了arm就崩溃了。
5. 第三方库，不是所有第三方的库都有arm版，或者也能在arm下编译的。

引申问题是“为什么现在Windows for ARM软件那么少？”

首先，就是软件“可用”和软件“质量”相同完全就是两回事。软件主要逻辑跑起来了，但是bug一堆。putty开源软件，随便怎么折腾没关系。Adobe这样的大公司可不敢胡来，Photoshop点个画笔就崩溃，谁也不能接受吧。要问这些bug怎么来的，那简直就太多了。

最简单的，自增，i++，够简单了吧？x86是原子操作，意味着多线程操作一个只做++ --的变量不用加锁。而ARM平台++可不是原子操作。如果一个程序一开始就没考虑过跨平台问题，程序逻辑里面这种想当然的假设多如牛毛。另外一方面，API具体的兼容程度又到了哪一步？Win32作为一个兼容Win16的API，必然有针对Win16做的兼容举措。有些程序已经对这种“兼容”做了兼容，而ARM是全新平台，微软会不会去掉了这些兼容举措？

说起来令人震惊，但是Windows作为一个操作系统，也不时的要给应用打patch。到了新的平台，Windows还会给你打这些patch吗？

计算机是个精密的系统，同时也是一个充满了假设的系统。说的不好听点，就是CPU的名字从x86变到ARM都会让一票软件崩溃。

有了这些bug，企业必然要评估做还是不做？

这就引出第二点，

微软根本就不开放Win32 for ARM。只为他自己的Office和特定合作伙伴开放，意味着前面的假设根本不成立，句号。

为什么要有操作系统？为什么要有高级语言？主要目的之一不就是为了抹平不同硬件平台的差异么？

许多软件连简单修改都不用，甚至重编译都不用。新CPU平台上直接就能跑。简单来说程序分成以下几大类：

1. 非本地码，高级语言程序。包括解释型程序（各大脚本语言），中间码程序（JAVA，C#等），理论上来说，无须任何修改，完全无痛迁移。实践上很多程序确实就能做到。比如Metro App，同一个程序，无论你在ARM的Windows RT上还是x86的Win 8上都一样跑。

2. 本地码，用户态高级语言程序。包括著名的C、C++、Pascal等直接编译成CPU指令的高级语言。这些语言的程序，理论上重新编译后就能运行在另一款CPU上。
   
   前两类程序的移植性有一个重要前提：这个程序没有直接使用任何当前CPU专有的特性。比如内嵌汇编，或者特定平台的特有扩展，或者假定指针长度等。如果有，那么这部分必须修改或者重写。这些不可移植的写法有的是为了优化，无可厚非，比如内嵌汇编。有的就是程序的不良设计需要尽量避免，比如假定指针长度。实践上，使用专有特性的程序是很多的。将他们移植到另一款CPU上会有不少工作量。但是没有这个包袱，移植很轻松的程序也是很多的。

3. 编译器和解释器。本地码语言的编译器的后端（生成目标代码的程序）肯定是需要重写的，这是自然而然的事情。非本地码语言的编译器，以及解释型语言的解释器，理论上可以做到不需要重写。但是这些程序一般为了效率起见会大量使用所在平台特有技术进行优化，实践上是要修改，甚至几乎要重写。
   

4. 系统程序，说白了就是操作系统核心。这个东西当然需要重写。他是硬件和前三类程序的沟通桥梁。

对于Windows RT和Windows 8，有一个情况不得不提，那就是Win32 API的问题。Windows RT没有开放Win32 API，这意味着Windows RT在理论上并不是一个完整的Windows ARM版。这个系统只有Metro API，没有Win32 API。而传统的x86 Windows软件使用的都是Win32 API，他们是无法在Windows RT上运行的，不能直接跑，也不能移植，只能从零使用Metro API重写。完整版的Windows ARM版现在只存在于微软内部。（Win 10出来后也许会公开发布？）而如果是Metro API上写出的程序，那程序天生就能跨CPU。

Linux、BSD等开源系统大量跨平台，他们的软件有很多是靠源代码发行的，这些软件很大程度上就做到了各CPU平台都能直接编译运行。