1

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

我只是想知道将程序移植到不同的芯片组意味着什么。作为一名 Java 程序员，我对底层细节知之甚少。

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

我当然知道这个过程不是那么简单，所以我想了解一下理论上的限制、可能的问题等等，这可能会使这个过程变得困难。

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

4

3 回答 3

2

计算机程序在本质上往往完全不同。你可以有一个微不足道的“你好世界！” 例如，您还可以拥有一个成熟的操作系统。

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

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

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

ARM 和 x86 世界之间存在很大差异。在 x86 中，几乎所有东西都是标准化的（听说过兼容 IBM PC吗？），许多供应商都在构建架构的克隆。相反，在 ARM 生态系统中，ARM 公司本身只是一个 IP 提供商，每个供应商之间都有细微到很大的差异（只需检查 arch 文件夹中以 mach 开头的子目录名称 - 用于机器，或 plat - 用于平台） . 对于 ARM，在UEFI的最新开发尚未广泛实施之前，您没有 BIOS 之类的东西（我并不是说 BIOS 是好还是坏，只是一个例子）。

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

我期待 MS 严格定义 Windows 可以在什么样的 ARM 机器上运行，与非常开放的 Linux 世界相比，可以在什么样的外围设备上运行，以确保质量和上市速度。

这是我能想象到的两大问题，但是每转一圈都会出现一些小问题，比如；ARM 是 32 位 RISC 架构，char 是无符号的，即使是最近的高端 ARM 内核也不支持整数除法（性能？），所有那些 Windows 代码认为理所当然的小东西可能会咬他们回来......

于 2012-11-30T15:53:21.250 回答
1

问题有所不同，但通常属于以下领域：

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

  2. 程序员做出不正确的假设。例如，假设 along是 32 位。这些可以是真正的猪找到和修复。

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

  4. 真正的架构差异：例如，大端/小端问题、文件名格式等。

于 2012-11-30T14:37:21.957 回答
1

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

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

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

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

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

于 2012-11-30T15:52:24.453 回答