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

Question

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

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

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

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

注意:这个问题并不特定于我提到的例子

Answer 1

计算机程序在本质上往往是完全不同的。你可以有一个微不足道的“ Hello World !”例如，那么您还可以拥有一个成熟的操作系统。

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

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

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

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

对于操作系统的“扩展机器”角色，Windows 就是这样，移植应该相对容易一些。这主要是关于像调用硬盘分区“c:”这样的特性——拥有像只读或隐藏这样的文件权限，并保持像 Win32 API 这样的核心 API 的大部分功能。这又不是straight forward .

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

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