将现有代码库移植到不同的芯片组

Question

我听说微软在ARM芯片组上移植了Windows。

我只是想知道将程序移植到另一个芯片组意味着什么。作为一名Java程序员，我对低级细节知之甚少。

天真地我认为Windows是用C，C ++和C＃混合编写的。我很确定ARM已经有了它的C和C ++编译器，所以这些代码应该只使用这些编译器重新编译。 C＃需要.NET解释器，它也可能用低级语言编写，理论上可以用ARM特定的C或C ++编译器重新编译。

我当然知道程序并不那么简单，所以我想了解理论上的局限性，可能出现的问题等等，这些都会使这样的程序变得困难。

注意：问题并非特定于我提到的示例

Answer 1

计算机程序的性质往往差异很大。你可以拥有一个微不足道的“你好世界！”例如，那么你也可以拥有一个成熟的操作系统。

具有经典定义（来自Tanenbaum）的“作为扩展机器的操作系统”和“作为资源管理器的操作系统”的操作系统需要提供许多东西。

当操作系统需要充当资源管理器时，它只是运行在底层机器的基础上，控制其功能，如启动，中断，I / O，安全模式等。虽然我们无法查看Windows的源代码代码看看这些方面有什么不同，我们可以看看它已经在x86和ARM体系结构上运行的开源竞争对手 - Linux！

Linux对不同体系结构的支持位于arch目录中。例如，我们有许多其他目录中的x86和ARM目录。我相信即使检查那里的目录名称也会给你提示所需的工作量（启动，电源，内存管理等）。

ARM和x86世界之间存在很大差异。在x86中，几乎所有东西都是标准化的（曾经听说过IBM PC compatible？），许多供应商构建了一个体系结构的克隆。相反，在ARM生态系统中，ARM公司本身只是一个IP提供商，每个供应商之间都有轻微的差别（只需检查以mach开头的arch文件夹中的子目录名称 - 这是机器或平台 - 用于平台） 。使用ARM之前，在UEFI最近的开发之前你还没有像BIOS一样的东西，但仍然没有大量实现（我不是说BIOS是好事还是坏事，只是一个例子）。

对于操作系统的“扩展机器”角色，它使Windows成为现实，移植应该相对容易一些。这主要是关于调用硬盘分区“c：”等功能 - 拥有像只读或隐藏的文件权限，并保持像Win32 API这样的核心API大部分功能。然而，这不是straight forward。

我希望MS能够严格定义Windows可以运行什么样的ARM机器，使用什么样的外围设备与非常开放的Linux世界相比，以确保质量和产品上市速度。

这是我能想象到的两大问题，然而每次转弯都会出现小问题，如： ARM是32位RISC架构，char是无符号的，即使是最近的高端ARM内核也没有整数划分支持（性能？），Windows代码认为理所当然的那些小东西可能会让他们反感......

Answer 2

问题不同，但一般都属于这些方面：

1. 使用非标准功能的地方。例如，在块中的可执行代码之后声明变量在ANSI C中无效，但在C99和C ++中。但微软编译器不支持C99。与此相关的是标准中未涉及的任何地方，例如流程创建CreateProcess v.fork / exec，信号处理等。

2. 程序员做出错误的假设。例如，假设long是32位。这些可以是真正的猪找到并修复。

3. 编译器不符合标准。这些日子不太常见。更常见的是在某些平台上缺乏库实现。当然标准并不完美，有时可能会对同一标准有不同的解释。

4. 真正的架构差异：例如，big endian / little endian问题，文件名格式等。

Answer 3

尽管操作系统上的绝大多数代码都是用C语言编写的，但仍有相当大的部分用汇编语言编写。这将需要移植到新平台。其中一些是刚刚完成的，因为它更有效（像memcpy这样的东西）但是编写了一些程序集，因为没有等效的C指令（比如进行系统调用或正确处理自旋锁）。所有这些都需要移植。

操作系统也直接访问硬件，并且会有一小部分硬件，如定时器等，这对操作系统的工作至关重要。所有这些都需要移植。

在需要内存管理单元（MMU）的保护模式操作系统中，必须移植执行MMU处理的代码。

这在某种程度上将从操作系统的其余部分中抽象出来，但其中一些抽象可能基于某些假设。在这种情况下，需要修复这些说明才能使所有这些工作正常。

然后有大量的驱动程序需要移植到新硬件上。