程序数据模型由OS还是硬件架构决定？

文章目录

前言
硬件架构的作用
OS的作用
编译器的角色
OS的数据模型
参考

前言

在文章 1>>32的结果是1还是0 中提到了数据模型 $L P 64$ ，并提出这个数据模型主要是由 $U ni x$ 以及类 $U ni x$ 的操作系统使用居多，例如 $L in ux$ 。

除 $L P 64$ 外，在 $64 bi t$ 下还有其余的数据模型，如下表所示：
在这里插入图片描述上表中 $I L P 32$ 数据模型也用于许多具有 32 位处理器的平台。该模型减少了代码大小和包含指针的数据结构的大小，但代价是地址空间更小，适合嵌入式系统。

看过了上述所有数据模型，我们会引出疑问：对于C语言程序，用户书写代码并通过编译器编译为可执行文件执行，那么在这个过程中，由谁来决定数据模型的选择，是OS还是硬件架构，编译器又扮演什么角色？

巧的是，已经有人在 $St a c k O v er f l o w$ 上问过这个问题了，原链接在文末。

硬件架构的作用

我们知道，现在应用最为广泛的 $64$ 位指令集架构是 $x86\_64$ ，又名 $am d 64$ 或 $x 64$ 。它是 $am d$ 公司在 $I n t e l$ 的 $i 386$ 的基础上于 $1999$ 年提出的指令集，主要优点在于能够在 $64 bi t$ 机器上运行 $32 bi t$ 指令。所以我们在当前 $64 bi t$ 机器上也可以运行 $32 bi t$ 可执行程序。

但在此我们以 $R I SC V$ 指令集 $R V 64 I$ 为例。其提供指令 $L D$ ， $L W$ ， $L H$ 和 $L B$ 用于加载数据。其中， $L D$ 加载 $64$ 位数据到寄存器， $L W$ 用于加载 $32$ 位数据并符号扩展到 $64$ 位寄存器， $L H$ 用于加载 $16$ 位数据并符号扩展到 $64$ 位寄存器， $L B$ 用于加载 $8 bi t$ 数据。
同样的，用于加载数据并零扩展的指令有： $L W U$ ， $L H U$ ， $L B U$ 。
用于存储数据的指令有： $S D$ ， $S W$ ， $S H$ ， $SB$ 。

根据上述我们知道一个 $R I SC V$ 硬件可能支持多种操作模式，从 $8 - 64 bi t$ 。

但只有硬件不够，还需要有OS的支持。我们可以在 $64 bi t$ 处理器上运行 $32 bi t$ 的OS，同时还可以在 $64 bi t$ 的OS上运行 $32 bi t$ 的用户程序。

OS的作用

在运行 $L in ux$ 中的程序时，程序可以遵循 $I L P 32$ 和 $L P 64$ 模型。当我在 $Win d o w s$ 系统时，程序可以遵循 $I L P 32$ 和 $LL P 64$ 模型。因此，即使在同一组硬件上，可以有两个操作系统待选择，不同OS在编译时又有两个“平台”可供选择。

以 $L in ux$ 为例，用户在编译时的选择中的两个常见的 $L in ux$ 平台为 x86_64-pc-linux-gnu 和 i386-pc-linux-gnu，分别对应 $64$ 和 $32$ 位用户程序。

编译器的角色

编译器主要对用户程序产生影响，我们知道，在 $L in ux 64$ 位系统中使用 $GCC$ 编译程序时可以选择编译为 $32$ 位或选择默认编译为 $64$ 位可执行程序。那么编译器会根据编译参数，同时结合当前OS，即用户所处环境，强制用户程序所遵循的数据模型。

例如：用户在 $l in ux 64$ 下取用默认选项，那么其可执行程序为 $64 bi t$ 程序且数据模型为 $L P 64$ 。同样的，在 $w in d o w 64$ 下我们使用 $\ Studio$ 指定编译选项为 $x 64$ 时，其数据模型为 $LL P 64$ 。用户指定编译结果为 $32 bi t$ 的话则统一编译为数据模型为 $I L P 32$ 的可执行程序。

OS的数据模型

OS作为一种系统软件其必须遵循一种数据模型。OS的数据模型一定程度上受到硬件架构的影响，其选择的数据模型在所处硬件上必须支持，同时OS可以在范围内有自己的选择，这也导致了 $L in ux$ 和 $Win d o w s$ 数据模型的不同。

例如：32位处理器OS可以选择 $I L P 32$ 和 $L P 32$ 数据模型，但是在 $L P 32$ 数据模型中， $in t$ 大小为 $16 bi t$ ，那么在 $i 386$ 的处理器则不支持，由于在 $32 bi t$ 模式下 $16 bi t$ 数据的操作码比 $32 bi t$ 更长更慢。